HTTP API 설계 예시

회원 관리 시스템

POST 신규 자원 등록 특징

• 클라이언트는 등록될 리소스의 URI를 모른다.
  ex)members/100 100이 URI
• 서버가 새로 등록 된 리소스 URI를 생성해준다.
  - 컬렉션
  서버가 관리하는 리소스 디렉토리
  서버가 리소스의 URI를 생성하고 관리
  여기서 컬렉션은 /members

API 설계 post 기반 등록

• 회원 목록/members ->GET
• 회원 등록/members ->POST
• 회원 조회/members/{id}->GET
• 회원 수정/members/{id}->PATHC, PUT, POST
• 회원 삭제/members/{id} -> DELETE

리소스를 기반으로 등록해야 함

파일 관리 시스템

API 설계 PUT 기반 등록

• 파일 목록/files ->GET
• 파일 조회/files{filename} ->GET
• 파일 등록/files{filename} ->PUT
  있으면, 덮어버리고 있으면 새로 생성한다. 그래서 포스트 대신, 풋을 사용한다.
• 파일 삭제/files{filename} ->DELETE
• 파일 대량 등록/files -> POST

PUT 신규 자원 등록 특징

• 클라이언트는 등록될 리소스의 URI을 알고 있어야 한다.
  ex)- 파일 등록/files{filename} ->put
  클라이언트가 직접 리소스의 URI를 지정한다.

• 스토어
  클라이언트가 관리하는 리소스 저장소
  클라이언트가 리소스의 URI를 알고 관리한다.
  여기서 스토어는 /files

  ---

  대부분 post 기반에 컬렉션을 많이 사용함.

  HTML FORM 사용

  • 순수한 html은 get, post만 지원한다. 따라서 제약이 있다

• 회원 목록/members ->GET
• 회원 등록 폼/members/new ->GET
• 회원 등록 /members/new ->POST
  여기서 리플레쉬 할 경우, 다시 폼으로 돌아가야하기 때문에 등록 폼과 등록의 uri를 맞춰주는게 좋다.

• 회원 조회/members/{id}->GET
• 회원 수정 폼/members/{id}/edit ->GET
• 회원 수정/members/{id}/edit ->POST
• 회원 삭제/members/{id}delete -> POST

컨트롤 URI

회원을 삭제하고 싶은데, delete 메소드를 사용할 수 없기 때문에
컨트롤 uri(동사로 된 경로)를 사용해서
id 뒤에 delete를 붙여주고 post로 보낸다.

컨트롤 URI를 최대한 사용하지 않고, 어쩔 수 없을 때 대체제로 사용하는 정도로 생각하자. 우리는 리소스 자원을 구분해야하기 때문에!

참고하면 좋은 URI 설계 개념

• 문서 (document)
  단일 개념(파일 하나, 객체 인스턴스, 데이터 베이스 열)
• 컬렉션(collection)
  서버가 관리하는 리소스 디렉토리
  서버가 리소스 uri를 설계하고 관리한다.
  예) /members
• 스토어(store)
  클라이언트가 관리하는 자원 저장소
  클라이언트가 리소스의 uri를 알고 관리한다.
  예) /members/100-컨트롤러, 컨트롤 uri
  문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
  동사를 직접 사용한다.
  예) /members{id}/delete