회원이라는 개념 자체가 바로 리소스이다.
회원이라는 리소스만 식별하면 된다. -> 회원 리소스를 URI에 매핑
리소스는 명사, 행위는 동사 (미네랄을 캐라)
행위(메서드)는 어떻게 구분하나?
GET : 리소스 조회
서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)을 통해서 전달
메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음
요청
GET /members/100 HTTP/1.1
Host: localhost:8080
서버에서 데이터를 생성해서 응답 데이터를 client에 보낸다
POST : 새 리소스 생성(등록), 요청 데이터 처리(프로세스 처리), 다른 메서드로 처리하기 애매한 경우 POST 처리(JSON으로 조회 데이터를 넘겨야 하는데 GET메서드를 사용하기 어려운 경우)
POST /members로 지정
대상 리소스가 리소스의 고유 한 의미 체계에 따라 요청에 포함 된 표현을 처리하도록 요청한다.
HTML 양식에 입력 된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공한다.
게시판, 뉴스 그룹, 메일링 리스트, 블로그 또는 유사한 기사 그룹에 메시지 게시
서버가 아직 식별하지 않은 새 리소스 생성한다.
기존 자원에 데이터 추가
정리 : 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 한다. -> 정해진 것이 없다.
PUT : 리소스를 삭제하고 완전 대체, 해당 리소스가 없으면 생성 (덮어버림)
기존 리소스를 수정할 수 없다. -> PATCH를 사용!!
클라이언트가 리소스 위치를 알고 URI지정한다.
PUT /members/100 으로 지정을 한다.
/members/100
{
"username": "young",
"age":20
}에서
PUT /members/100
Content-Type: application/json
{
"age":50
} username 필드가 사라진다. 리소스를 새로 덮어버린다.
PATCH : 리소스 부분변경
patch가 지원을 하지 않는 곳에서는 post를 사용하면 된다.
{
"age":50
}를
{
"username": "young",
"age":50
}으로 age만 50으로 변경한다.
DELETE : 리소스 삭제
DELETE/members/100 HTTP/1.1
Host: localhost:8080
HEAD : GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)를 설명(주로 CORS에서 사용)
CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행한다.
안전
호출해도 리소스를 변경하지 않는다. (안전은 해당 리소스만 고려한다.)
멱등 Idempotent (자동 복구 메커니즘)
한 번 호출하든 두 번 호출하든 결과가 똑같다.
중간에 리소스가 변경되는 것 까지 고려하지 않는다. (멱등이 아니다)
GET : 같은 결과가 조회
PUT : 결과를 대체한다. 여러번 해도 최종 결과는 대체이다.
DELETE : 결과를 삭제한다. 여러번 해도 삭제된다.
POST : 같은 결제가 중복해서 발생할 수 있기 때문에 멱등이 아니다.
캐시가능 Cacheable
한 번 받은 응답(결과)을 저장해두고, 다음에 또 같은 요청이 오면 다시 받아오지 않고 저장된 응답을 재사용해도 되는가?
GET, HEAD, POST, PATCH 캐시가능
실제로는 GET, HEAD 정도만 캐시로 사용 !!!
POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않다.