HTTP 웹 기본 지식 - HTTP API를 만들어 보자

HTTP 메서드

이번에는 HTTP 메서드 부분이다.

간단하게 HTTP AIP를 만들어 보고,

HTTP 메서드인 GET, POST

그리고 PUT, PATCH, DELETE 에 대해 알아보고,

HTTP 메서드의 속성에 대해서 알아보도록 하겠다.

 

HTTP API를 만들어 보자.

요구사항이 나왔다.

회원 정보 관리 API를 만들어야 하는데,

회원 목록 조회, 회원 조회, 회원 등록, 회원 수정, 회원 삭제 가 가능해야 한다.

그러면 먼저, URI를 설계해야 한다.

회원 목록 조회니까 read-member-list

회원 조회니까 read-member-by-id

회원 등록 이니까 create-member

회원 수정이니까 update-member

회원 삭제니까 delete-member

이런식으로 URI 이름을 지정했다.

이렇게 설계하는 것은 좋은 URI 설계일까?

URI를 설계할 때, 가장 중요한 것은 리소스 식별이다.

리소스가 뭘까?

회원을 등록하고 수정하고 조회하는게 리소스가 아니다!!

회원이라는 개념 자체가 리소스다.

회원을 등록하고 수정하고 조회하는 것을 모두 배제하고, 회원이라는 리소스만 식별하면 된다.

→ 회원 리소스를 URI에 매핑

리소스는 회원이다.

"리소스는 리소스답게 설계를 해야지!!" 라고 배우고 막상 설계를 해보면 이렇게 된다.

URI는 계층 구조를 활용해야 하므로,

회원 목록 조회는 회원이 하나가 아니고 회원을 여러개 합쳐 놓은 것이므로, 복수형으로 members라고 썻다.

그런데 문제는,  회원 조회, 회원 등록, 회원 수정, 회원 삭제 등을 설계할 때,
/members/{id} 형태로 설계를 하게 된다. 다 같은 리소스인 회원에 대해서 URI를 설계하기때문에 다 똑같아진다.

그러면  조회, 등록, 수정, 삭제는 어떻게 하지?? 라는 문제가 생긴다.

리소스라는 것이 "회원"이라는 것은 알겠는데,
URI는 어떻게 설계해야하는거지..?

가장 중요한 것은, 리소스 자체를 식별하는 것이다.

리소스와 행위를 분리해야 한다.

URI는 리소스만 식별!!

리소스가 회원이고, 그 리소스의 행위가 조회, 등록, 삭제, 변경 등이 된다.

리소스는 명사, 행위는 동사이다.

그러면 행위는 어떻게 구분할까?

그것은 바로 HTTP 메서드가 역할을해준다.
그렇기 때문에 우리는 URI로 리소스만 식별하면 된다.

다음시간에 HTTP 메서드에 대해서 알아보겠다.