이전 장에서 HTTP메시지
는 요청에 대한 행동을 담는다고 했습니다. 클라이언트측에서 서버에서 어떤 정보를 요청하는데 단순히 요청하는것 뿐만아니라 음식점에서 서버(Server)
에게 메뉴판을 보여주세요(GET,HEAD ..)
, 수정해주세요(POST, PUT, DELETE...)
등과 같은 행동을 담을 수 있습니다. 이 장에서는 메서드와 헤더에 대해 알아보겠습니다.
종류 | 설명 |
---|---|
GET | 리소스의 조회 |
POST | 요청 데이터 처리, 주로 등록에 사용 |
PUT | 리소스를 대체, 해당 리소스가 없으면 생성 |
PATCH | 리소스 부분 변경 |
DELETE | 리소스 삭제 |
HEAD | GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환 |
OPTIONS | 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용) |
CONNECT | 대상 자원으로 식별되는 서버에 대한 터널을 설정 |
TRACE | 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행 |
GET은 리소스를 조회하는데 일반적으로
Default
방식으로 서버에 있는 데이터를 보고싶을 때 사용합니다.
GET /search?q=hello&hi=ko HTTP/1.1
HOST: www.google.com
서버의 특정 경로에 있는 파일은 query
를 통해서 전달해서 받아옵니다.
메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않는다고 합니다.
POST는 메시지 바디
를 통해 서버로 요청 데이터를 전달합니다.
서버는 요청 데이터를 처리하는데, 주로 전달된 데이터로 신규 리소스를 등록하거나, 프로세스 처리(상태 업데이트
)에 사용됩니다.
신규 리소스를 등록하는것은 회원가입을 하면 그 회원을 위한 새로운 식별자를 생성해주는데 이 과정은 POST메서드
로 동작하게 됩니다.
POST /members -> /memebers/100 : 신규 리소스 식별자 생성
프로세스 처리의 경우는 배달 어플에서 배달을 시작하고 완료를 했을 때 배달이라는 상태를 변경할 때, 새로운 리소스를 만들지 않을때에도 사용이 된다고 합니다 (컨트롤 URI)
POST /oders/{orderId}/end-delivery
이렇게 보면 POST만으로 새로운 리소스를
변경
하거나새로 만들거나
아니면 GET처럼가져오기
만 할 수 있습니다. 따라서 리소스 URI에 POST요청이 오면 데이터를 어떻게 처리할지 개발자가리소스마다 따로 정해
야 합니다.
PUT은 리소스를 대체한다고 했습니다.
대체
생성
POST는 리소스의 정확한 위치를 모릅니다. 왜냐 새로운 리소스를 생성하고 그제서야 ID
값이 생겨나는 반면 PUT은 정확한 리소스의 위치를 지정해서 리소스를 대체하든지 생성하든지 합니다.
PUT /members/1234
위와 같은 요청이 들어왔을 때 1234의 ID가 없다면 바디의 내용으로 새로운 리소스를 만들고, 있다면 리소스를 대체하는식으로 동작합니다.
하지만 이 PUT
메서드의 경우는 주의해야할 점이 있는데요,리소스의 부분만을 선택해서 변경하지 못한다는 것 입니다.
그림에서 처럼 서버에 있는 리소스는 username과 age가 있었는데 새로 요청된 PUT메서드
로 age만 있는 리소스로 덮어씌워져 버리게 됩니다.
때문에 등장하게 된것이 바로 PATCH
입니다.
PATCH
는 그림처럼 리소스의 "일부분"
만 보낸다고 할지라도 전부 덮어씌우지 않고 해당 부분만 수정하게 됩니다.
DELETE
메서드는 정말 단순하게 해당 리소스를 삭제합니다. 삭제하기만 할 뿐이라서 HTTP메시지 바디에는 아무것도 들어있지 않아도 됩니다.
요청한 URI에 해당 리소스가 없다고 하더라도 에러가 나타나지 않습니다~
안전이라는 속성은 몇 번을 호출해도 리소스가 변경되지 않는가?
라는 속성입니다.
GET/HEAD/OPTIONS/TRACE
는 단순히 리소스를 불러오거나 경로에 대한 메서드이기때문에 몇번을 호출해도 리소스 자체는 변경하지 않
습니다.
f(f(f(f....(f(x))...) == f(x)
한 번 호출하든 n번 호출하든 결과가 똑같다
라는 속성이 바로 멱등성 입니다.
안전
한 메서드들 뿐만 아니라 같은 바디 내용으로 요청을 보내더라도 항상 결과가 동일한 메서는 리소스를 수정하는 PUT
도 추가됩니다.
POST의 경우는 리소스를 새롭게 생성하는 행위를 갖고있기때문에 여러번 수행하면 매번 새로운 리소스가 생성된 것이고, 연산을 수행하는 결과가 달라지는 것을 확인할 수 있습니다.
결제하는 POST를 두 번 호출하면 같은 결제가 중복해서 발생할 수 있습니다.
하지만 PUT과 유사한 PATCH
는 왜 멱등하지 않는것일까?
PATCH
메서드가 명세서에 나온것처럼 단지 일부분만 변경한다면 멱등성이 성립한다고 합니다. 하지만
PATCH users/1 { $increase: 'age', value: 1, }
이처럼 age라는 필드값을 증가시킨다는 요청을 보내면 이 API는 멱등하지 않습니다. 매번 수행할때마다 1씩 증가하기때문입니다.
멱등성이 있는 메서드의 요청이라면 서버가 에러로 응답을 못줬을 때, 클라이언트가 같은 요청
을 다시 해도
된다는 근거가 됩니다.
즉 어플리케이션이 예상하지 못한 방향으로 동작하는 것을 방지할 수 있습니다.
캐시를 사용하면 원서버로부터의 응답을 기다리지 않고 바로 저장하고 이전의 응답(캐시
)을 사용해서 빠른 처리가 가능해집니다. 그렇다면 어떤 메서드가 캐시가능할까요?
우선 현재 시점의 응답이나 권한 있는 응답에 의존하지 않는
안전한 메서드
는 캐시 가능한 것으로 정의합니다.
요청에 사용되는 GET
또는 HEAD
메서드는 캐시할 수있습니다. 새로 고쳐지거나 콘텐츠 위치 헤더가 설정되어 있는 경우 POST
또는 PATCH
요청에 대한 응답을 캐시할 수도 있지만 구현되지는 않습니다. (예를 들어, 파이어 폭스는 지원하지 않습니다. https://bugzilla.mozilla.org/show_bug.cgi?id=109553.)
PUT
또는 DELETE
와 같은 다른 메서드는 캐시할 수 없으며 결과를 캐시할 수 없습니다.
응답의 상태 코드는 응용 프로그램 캐싱에 의해 알려져 있으며 캐시 가능한것으로 간주됩니다. 다음 상태 코드는 캐시할 수 있습니다: 200, 203, 204, 206, 300, 301, 404, 405, 410, 414,및 501.
캐싱을 방지하는 캐시 컨트롤과같은 응답에 특정 헤더가 있습니다.