🎈 API URI
API URI는 리소스를 식별하는 용도로 사용해야 함
회원 조회, 회원 등록, 회원 수정, 회원 탈퇴 등등... -> 회원
회원 이라는 리소스를 가지고 어떤 행위를 수행할지는 HTTP 메서드를 통해 구분한다.
리소스와 메서드 조합으로 다 구분할 수 없는 경우에만 컨트롤 URI(동사)를 사용한다.
🎈 HTTP 메서드 종류
🔰 GET: 조회
- 전달하고 싶은 데이터는 쿼리 파라미터, 쿼리 스트링 등으로 전달한다.
- requestBody는 지원하지 않는 곳이 많아서 권장하지 않음
🔰 POST: 데이터 처리 (주로 등록)
- requestBody를 통해 처리할 데이터를 전달
- 등록 뿐만 아니라 단순한 값 변경을 넘어서 큰 변화가 일어나는 경우
- 다른 메서드로 처리하기 애매한 경우 (조회 해야 하는데 requestBody가 필요한 경우)
- 컨트롤 URI
- PATCH 메서드를 지원하지 않는 경우
🔰 PUT: 덮어쓰기
- 리소스가 이미 있으면 대체하고, 없으면 생성한다.
- 리소스의 식별자를 클라이언트가 알고 있어야 함
PUT /members/100 HTTP1.1 (식별자 앎)
POST /members HTTP1.1 (식별자 모름)- 리소스가 완전히 덮어쓰기 되므로, PUT으로 특정 필드만 보내면 다른 필드는 삭제됨 (수정을 위해서는 모든 필드 값을 보내야 함)
🔰 PATCH: 부분 변경
- 특정 필드 값만 변경할 수 있음
🔰 DELETE: 삭제
🔰 기타
HEAD: 조회인데 요청메세지와 응답메세지 없이 헤더만 주고받고 싶을 때OPTIONS: CORS 권한 및 안전 확인용 사전 요청
🎈 HTTP 메서드의 속성
🔰 안전 (Safe)
- 호출했을 때 리소스가 변경되지 않음
GET,HEAD
🔰 멱등 (Idempotent)
- 몇 번을 호출하든 결과가 똑같음
GET,PUT,DELETE- 멱등한 메서드는 서버에서 응답이 없을 때 클라이언트에서 자동으로 재요청을 보내도 괜찮다
🔰 Cacheable
- 응답을 브라우저에서 캐싱해서 사용할 수 있음
GET,HEAD,POST(잘 안함),PATCH(잘 안함)POST,PATCH는 캐시 키로 requestBody 내용을 구현하기 어려워서 잘 사용하지 않음
