=> 애초에 API URI를 짤 때 '리소스'를 기준으로 두고 고민해야 한다.
- 동사에 초점을 잡는게 아니라 '주어'인 대상(리소스)을 중심으로 생각하자.
- 리소스[명사] : 회원
- 행위[동사] : 조회,등록, 변경, 삭제
ex) 회원 등록, 수정, 삭제, 조회 => '회원' 리소스
회원 목록 조회 /members
• 회원 조회 /members/{id}
• 회원 등록 /members/{id}
• 회원 수정 /members/{id}
• 회원 삭제 /members/{id}
참고: 계층 구조상 상위를 컬렉션으로 보고 복수단어 사용 권장(member -> members)
• GET: 리소스 조회
• POST: 요청 데이터 처리, 주로 등록에 사용
• PUT: 리소스를 대체, 해당 리소스가 없으면 생성
• PATCH: 리소스 부분 변경
• DELETE: 리소스 삭제
• HEAD : GET과 기본적으로 동일하나 body부분을 제외한 서버 리소스의 헤더와 상태줄만 반환
• OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
• CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
• TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행
요청한 URI를 통해 해당 /members/100에 가서 데이터를 요청했고 응답 받았다.
예시를 보면서 들으면 이해가 쉽다
• HTML 양식에 입력 된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공
ex HTML FORM에 입력한 정보로 회원 가입, 주문 등에서 사용
• 게시판, 뉴스 그룹, 메일링 리스트, 블로그 또는 유사한 기사 그룹에 메시지 게시
ex 게시판 글쓰기, 댓글 달기
• 서버가 아직 식별하지 않은 새 리소스 생성
ex 신규 주문 생성
• 기존 자원에 데이터 추가
ex 한 문서 끝에 내용 추가하기
곧 1) 새 리소스 생성(등록), 2) 요청 데이터 처리(변경을 넘어서 프로세스를 처리해야 하는 경우) 3) 다른 메서드로 처리하기 애매한 경우
=> 3번의 경우 보통 GET 메서드 대신해서도 쓰는 경우가 있음.
/members/100 의 age key의 값이 50으로 변경되고 나머지 "username" : "young"으로 그대로 유지됩니다.
내 생각...
그리고 따로 응답메시지는 받지 않는 것 같다.
이 중 마지막인 idempotent(멱등성)의 경우,
- GET은 서버의 데이터나 상태를 변경시켜선 안된다.=> 멱등성이 ㅇ
- POST의 경우 서버에게 몇 번이고 같은 요청을 보내도 응답은 항시 다를 수 있음.
=> POST는 서버의 상태나 데이터 등을 변경시킬 때 주로 씀 (멱등성 x)