[HTTP] HTTP API 만들어보기 1 - 리소스와 행위의 분류

요구사항 V0

회원 정보 관리 API 를 만들어야한다. 요구 사항은 다음과 같다.

1. 회원 목록 조회

2. 회원 조회

3. 회원 등록

4. 회원 수정

5. 회원 삭제

---

API URI 설계 절망편

일단 최대한 직관적으로 설계해본다.

1. 회원 목록 조회 -> /read-member-list

2. 회원 조회 -> /read-member-by-id

3. 회원 등록 -> /create-member

4. 회원 수정 -> /update-member

5. 회원 삭제 -> /delete-member

최대한 직관적으로 작성해보았는데, 이게 과연 최선의 설계일까?

우리가 중요하게 생각해야할 것은 리소스를 식별할 수 있어야한다는 점이다 !

---

어떤 방식을 적용하면 좋을까?

먼저 리소스가 뭔지 리마인드 해보자.

회원을 등록하고 수정하고 조회하는게 리소스가 아니라, 회원이라는 개념 자체가 리소스이다 !

그렇다면 어떻게 식별하는 것이다 가장 좋은 방식일까?

일단 회원을 등록하고, 수정하고, 조회하는 것을 모두 배제하고, 우리는 회원이라는 리소스를 식별하는데 포커스를 두는 것이 좋다

즉 회원 리소스 자체를 URI에 매핑하는 방식을 생각해보자.

그렇다면 요구사항을 어떤 관점에서 보는 것이 좋은지 한번 알아보자.

---

요구사항 V1 -> URI 계층 구조 활용

각 기능의 리소스에 주목하여 URI를 만들어보자.

리소스를 식별하기 위해선 URI 계층 구조를 활용하는 것이 적절하다.

1. 회원 목록 조회 -> /members

2. 회원 조회 -> /members/{id}

3. 회원 등록 -> /members/{id}

4. 회원 수정 -> /members/{id}

5. 회원 삭제 -> /members/{id}

일단 이렇게 중심 리소스에 포커스를 둔 뒤, 해당 URI를 어떻게 구분하면 좋을지 생각해보면 된다.

 

리소스와 행위를 분리하자

URI는 위처럼 리소스만 식별한다. 그리고 우리는 해당 리소스를 대상으로 하는 행위를 분리해야한다.

예를 들어, 리소스는 회원이고 행위는 조회, 등록, 삭제 등등이다. -> 자세히 보면 리소스는 명사, 리소스를 분류하는 행위는 동사임을 확인할 수 있다.

그렇다면 행위는 어떻게 구분해야할까?

이제 바로 우리가 사용하는 GET,POST,PATCH 등등의 HTTP 메서드를 활용해야 한다.

HTTP 메서드는 다음 포스팅에서 이어하겠다 !