일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- thymeleaf
- VUE
- JPA
- Excel
- Vue.js
- 라이프 사이클
- HTTP
- 프로토타입
- vuex
- js
- cache
- Setter
- 싱글톤
- HTTP 메서드
- 의존성 주입
- Spring
- di
- 캐시
- BEAN
- vue-cli
- DB
- dependency injection
- Repository
- 로그인
- Kotlin
- Stateless
- Security
- Singleton
- javascript
- Java
- Today
- Total
jhhan의 블로그
HTTP 메서드(3) 본문
이번 포스트에서는 HTTP 메서드를 이용해서 API를 만들 때
생각해봐야 되는 부분에 대해서 알아보려고 합니다.
HTTP 메서드에 대해서 어느정도 알아봤으니
이제 HTTP API를 어떤 식으로 만들어야 할지 생각해 봅시다.
EX) 회원 정보 관리 API를 작성하기
- 회원 목록 조회
- 회원 상세 조회
- 회원 등록
- 회원 수정
- 회원 삭제
일단 되는데로 만들어본다면..
- 회원 목록 조회 : /get-all-members
- 회원 상세 조회 : /get-member
- 회원 등록 : /create-member
- 회원 수정 : /update-member
- 회원 삭제 : /delete-member
이런 식으로 만들 수 있을 것 같습니다.
왠지 느낌 상 저런 식으로 만들면 안 될 것 같다는 느낌이 듭니다.
(잘 만들었다는 느낌이 들지는 않죠)
그래서 저는 HTTP 메서드에 대해 간단히 익힌 후 아래와 같이 만들었습니다.
- 회원 목록 조회 : /get/members
- 회원 상세 조회 : /get/member/{id}
- 회원 등록 : /create/member/{id}
- 회원 수정 : /update/member/{id}
- 회원 삭제 : /delete/member/{id}
그 당시 저는 이런 방식으로 만들어서 진행했습니다.
그리고 나중에 가서 저런 식으로 하면 안되는 구나 라는 것을 배웠습니다.
HTTP 메서드를 만들 때 가장 중요한 것은 '리소스 식별' 입니다.
ex) 미네랄을 캔다 → 미네랄이 리소스에 해당!
- '미네랄을 캔다' 가 리소스가 아니라는 것입니다.
- 리소스에 대해서 생각을 해본다면 → 등록, 수정, 삭제 등의 행위를 배제하고 생각해보기
그러면 회원 정보 관리 API에서 리소스는 무엇일까요?
→ '회원'이 리소스가 됩니다.
그리고 리소스 식별이 중요하다고 했죠?
그러면 이제 '회원'이라는 리소스를 식별할 수 있으면 됩니다.
→ 회원을 URI에 매핑하면 됩니다!!
그러면 이제 다시 URI를 다시 만들어보면..?
- 회원 목록 조회 : /members
- 회원 상세 조회 : /members/{id}
- 회원 등록 : /members/{id}
- 회원 수정 : /members/{id}
- 회원 삭제 : /members/{id}
이렇게 하면 됩니다.
... 회원 목록 조회는 괜찮지만 나머지 4개의 URI가 겹치는 군요..
이 문제는 어떻게 해결해야 할까요?
URI는 리소스만 식별합니다.
그러면 이제 해당 리소스를 대상으로 하는 행위를 분리해야 합니다.
- 리소스 : 회원
- 행위 : 조회, 등록, 수정, 삭제 등
리소스 == 명사 행위 == 동사 라고 생각하면 편합니다.
그러면 행위는?
이전 포스트에서 제가 이미 다뤘었죠 ㅎㅎ
GET, POST, PATCH, PUT, DELETE을 사용하면 됩니다.
그렇게 해서 다시 URI를 만들면
- 회원 목록 조회 : GET /members
- 회원 상세 조회 : GET /members/{id}
- 회원 등록 : POST /members/{id}
- 회원 수정 : PATCH(PUT) /members/{id}
- 회원 삭제 : DELETE /members/{id}
이런 식으로 구성하면 됩니다.
수정의 경우 PUT 혹은 PATCH 중에 원하는 것을 사용하면 됩니다.
그래서 URI에는 명사만 사용하는 것이 좋은 URI 설계라고 볼 수 있습니다.
...
하지만 실무에서 과연 이런 방식으로만 쓸 수 있을까요?
아마 힘들겠죠 ㅎㅎ
일단 조회, 등록, 수정, 삭제 말고도 다른 프로세스가 굉장히 많을 것입니다.
그런 경우에도 위에 나온 예시만을 적용하기는 힘듭니다.
그렇기 때문에 명사 외에도 동사도 일부 섞어서 써야 합니다.. ㅎㅎ
이런 URI를 컨트롤 URI라고 합니다.
- 이런 제약을 해결하기 위해 동사가 포함되는 리소스 경로 사용
- HTTP 메서드만으로 해결하기 어려울 때 사용
적절히 잘 사용해주도록 합시다 ㅎㅎ
이렇게 해서 HTTP 메서드를 이용해서 API를 만들 때 생각해봐야 되는 부분에 대해서 알아봤습니다.
이런 방식을 따르지 않고 진행하면 원칙을 무시하고 개발하는 것이기 때문에 좋지 않다고 합니다.
꼭 이렇게 해보도록 합시다.
출처 : 모든 개발자를 위한 HTTP 웹 기본지식 by 김영한
'HTTP' 카테고리의 다른 글
HTTP 헤더 (0) | 2022.01.23 |
---|---|
HTTP 헤더 & 바디 (0) | 2022.01.22 |
HTTP 메서드(2) (0) | 2022.01.16 |
HTTP 메서드 (0) | 2022.01.16 |
HTTP 메시지 (0) | 2021.12.12 |