[ HTTP ] API 설계 (Collection VS Store 방식)

회원 관리 시스템에서 POST 기반으로 API를 설계해본다고 가정하자.

- 회원 목록 /members -> GET

- 회원 등록 /members -> POST

- 회원 조회 /members /{id} -> GET

- 회원 수정 /members /{id} -> PATCH, PUT, POST

- 회원 삭제 /members /{id} ->DELETE

 

POST 방식의 특징

• 클라이언트는 등록될 리소스의 URI를 모른다.
• 서버가 새로 등록된 리소스 URI를 생성해준다. 서버가 새로운 회원을 식별하기 위한 URI를 생선한다.
• Collection 형식 이라고 한다. 서버가 관리하는 리소스 디렉토리이며 여기서는 'members'가 해당된다.

그렇다면 PUT 기반 등록은 어떻게 될까?

파일 관리 시스템에서 PUT 기반으로 API를 설계해본다고 가정하자.

- 파일 목록 /files -> GET

- 파일 등록 /files/{filename} -> PUT (없으면 새로 생성하던가 완전 덮어씌우던가)

- 파일 조회 /files/{filename} -> GET

- 파일 삭제 /files/{filename} -> DELETE

- 파일 대량 등록 /files -> POST

 

PUT 방식의 특징

• 클라이언트가 리소스 URI를 알고 있어야한다.
  파일 등록 /files/{filename} -> PUT
  PUT /files/star.jpg
• 클라이언트가 직접 리소스의 URI를 지정한다.
• Store 방식이라고 한다. 클라이언트가 관리하는 리소스 저장소이며 여기서는 'files' 가 해당된다.

 

대부분 POST 방식을 사용한다.

그런데 HTML Form은 GET, POST만 사용가능하다. 그렇게 되면 어떻게 메소드를 사용해야할까?

- 회원 목록 /members -> GET

- 회원 등록 폼 /members/new -> GET

- 회원 목록 /members /new, /members-> POST

- 회원 조회 /members /{id} -> GET

- 회원 수정 폼 /members /{id}/edit -> GET (서버에서 변경이 일어나는게 아니기 때문에 POST)

- 회원 수정 /members /{id}/edit, /members /{id} -> POST

- 회원 삭제 /members /{id}/delete -> POST (Delete 메서드를 사용 못하기 때문에 Control URI 사용함.)

 

 

참고하면 좋은 URI 설계 개념

• 문서(document)
  단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)
• 컬렉션 (Collection)
• 스토어 (Store)
• 컨트롤러 (Controller), control URI
  문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
  동사를 직접 사용