HTTP API 설계 시작하기
- 요구사항 : 회원 등록, 수정, 조회, 삭제 기능을 가지는 회원 정보 관리 API가 필요하다.
1) 최초 설계
다음과 같이 URI을 설계했다.
이것이 좋은 설계일까? No
API URI 설계에서 가장 중요한 것은 리소스 식별이다.
회원을 등록, 수정, 조회하는 행위는 리소스가 아니다.
회원 자체가 바로 리소스다.
이 회원 리소스를 URI에 매핑하면 된다.
2) 개선한 설계
리소스와 행위로 나누자.
리소스 : 회원
행위 : 조회, 등록, 삭제, 변경
그럼 이들을 어떻게 구별해야 되지?
HTTP 메서드
주요 메서드
GET: 리소스 조회
POST: 요청 데이터 처리, 주로 등록에 사용
PUT: 리소스를 대체, 해당 리소스가 없으면 생성
PATCH: 리소스 부분 변경
DELETE: 리소스 삭제
GET
- 리소스 조회
- 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
- 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음
POST
• 요청 데이터 처리
• 메시지 바디를 통해 서버로 요청 데이터 전달
• 서버는 요청 데이터를 처리
• 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.
• 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
PUT
• 리소스를 대체(리소스가 있으면 대체, 리소스가 없으면 생성) => 덮어쓰기
• 중요한 점은 클라이언트가 리소스를 식별(/members/100) -> POST와의 차이점
• 클라이언트가 리소스 위치를 알고 URI 지정
• 주의할 점은 리소스를 완전히 대체하기 때문에 리소스 부분 변경이 불가능
PATCH : 리소스 부분 변경
DELETE : 리소스 제거
HTTP 메서드의 속성
- 안전(safe methods) : 호출해도 리소스가 변경되지 않음
- 멱등(Idempotent) : f(f(x)) = f(x), 한번 호출하든 여러번 호출하든 결과가 동일
(*POST는 멱등이 아니다. 두번 호출 시 결제가 중복해서 일어날 수 있음)
멱등은 자동 복구 메커니즘에 활용될 수 있다. 즉 서버가 정상 응답을 못주었을 때 클라이언트는 같은 요청을 다시 보내도 되는가?에 대한 근거가 됨
- 캐시가능(cacheable) : 응답 겨과 리소스를 캐시해서 사용해도 되는가?
GET, HEAD 정도만 캐시로 사용, POST와 PATCH는 본문 내용까지 캐시 키로 고려해야 되는데, 구현이 쉽지 않다.
-----------------------------------------
참고 : 인프런 김영한님 강의(모든 개발자를 위한 HTTP 웹 기본 지식)
댓글