우리가 API를 설계할 때 어떻게 만들어야할까?
회원 정보 API를 만들어보자.
- 회원 목록 조회 : ~/read-member-list
- 회원 조회 : ~/read-member-by-id
- 회원 등록 : ~/add-member
- 회원 수정 : ~/update-member
- 회원 삭제 : ~/delete-member
이렇게 만들어야할..것 같지만 아니다.
API에서 나타나야할 것은 리소스다.
회원을 등록하고 조회하고 삭제하는 행위는 리소스가 아니다.
여기서 리소스는 바로 회원이다.
따라서 위 API는 아래와 같이 표현하게 된다.
- 회원 목록 조회 : ~/members
- 회원 조회 : ~/members/{id}
- 회원 등록 : ~/members
- 회원 수정 : ~/members/{id}
- 회원 삭제 : ~/members/{id}
({id}는 임의의 회원 id가 유연하게 들어가는 데이터다.)
근데 이것만으로는 대체 어떤 API가 조회하고 등록하는지 알 수가 없다.
이 문제를 해결해주는 행위를 표현해주는 것이 HTTP 메소드다.
HTTP 메소드는 종류가 여러 개가 존재한다.
- GET : 리소스 조회
- POST : 요청 데이터 처리. 주로 리소스 등록
- PUT : 리소스를 대체(update에 가까움). 해당 리소스가 없다면 새로 등록
- PATCH : 리소스 부분 변경 (PUT과 다름)
- DELETE : 리소스 삭제
- 그 외 : HEAD, OPTIONS, CONNECT, TRACE
다음 글에서 해당 메소드들에 대해서 더 자세히 알아보도록 하겠다.
이번 내용은 쉽게 이해하기 좋은 비유 방식은 적절한 것이 없는 것 같다.
일종의 약속이라 생각하고 넘어가야 할 것 같다.
근데 위 설명에서는 API는 리소스로만 표현하도록 작성했지만
사실 실제로는 그렇지 않다.
실무를 하다보면 API를 리소스로만 표현하긴 안 좋은 상황도 존재한다.
그럴 땐 행위를 API에 표현해도 문제가 되지 않는다.
이와 관련해서도 차후 글에서 작성해보겠다.
반응형
'IT 공부 > 새로운 시작' 카테고리의 다른 글
HTTP(8) - HTTP 메서드을 알아보자(2) (0) | 2021.10.25 |
---|---|
HTTP(7) - HTTP 메서드을 알아보자(1) (0) | 2021.10.20 |
HTTP(5) - HTTP의 기본 특징(2) (0) | 2021.10.16 |
HTTP(4) - HTTP의 기본 특징(1) (0) | 2021.10.16 |
HTTP(3) - 웹 브라우저의 요청 흐름 (0) | 2021.10.10 |
댓글