HTTP Method의 스펙

0. 서론

식스펙

HTTP 요청 메서드 - HTTP | MDN

 

1. 본론

우선 각 요청에 대해 공통적으로 평가할 기준, Safe 와 Idempotent, Cacheable에 대해 간단히 보za

 

Idempotent는 앞선 포스팅들에서 언급한 바 있다. 멱등성이다.

동일 요청을 한 번 보내는 것과 여러번 보내는 것이 결과가 같고, 서버의 상태를 변화시키지 않는다면 멱등성을 갖는 것이다.

 

Safe, 안전함은, 멱등성의 상위 개념이다. (안전하면 멱등성을 갖지만, 멱등성을 갖는다고 안전한 건 아니다.)

예컨대 GET HEAD OPTIONS는 안전하고 멱등성을 갖지만, PUT DELETE는 멱등성은 갖되 안전하진 않다.

안전함은 다른 말로 읽기 작업만 수행하는 메서드라고 볼 수 있다.

(브라우저 입장에서 말그대로 안전하기 때문에, 서버에 해를 끼치지 않을 것을 보장하는 Safe한 요청에 의존하여 웹 크롤러도 동작할 수 있게 한다.)

https://developer.mozilla.org/ko/docs/Glossary/Safe/HTTP

 

Cacheable은 몰라도 크으은 상관은 없으나 다 정리하면 너무 길어서 링크를 첨부하고 짧게 소개한다.

말 그대로 캐시할 수 있는 HTTP 응답이고, GET과 HEAD 메서드는 요청에 사용된 메서드 그 자체로 캐시 가능하다.

https://developer.mozilla.org/ko/docs/Glossary/Cacheable

 

1-1. IETF RFC

https://ko.wikipedia.org/wiki/RFC

국제 인터넷 표준화 기구(Internet Engineering Task Force, IETF)는 전 세계에서 통용되는 인터넷에 대한 표준, 명세를 정의하는 단체이다.

RFC란 RFC 메모라고도 하는데, 새 인터넷 기술이나 연구 결과물을 담고 있는 일종의 웹 출판물이라고 보면 된다. 국제 웹 표준과 밀접한 관련이 있는 공신력있는 문서이다.

IETF에서 RFC 메모 형태로 문서를 출판하게 되는데, 매 RFC 문서마다 일련 번호가 주어지며, 일단 일련 번호를 부여 받고 출판되면, RFC는 절대 폐지/수정되지 않는다. 만약 수정이나 무효화가 필요하다면, 새로운 RFC 문서를 출판해서 덮어쓰는 방식으로 진행한다.

RFC 문서를 일련 번호로 나열하면, 인터넷 표준의 역사를 들여다볼 수 있는 셈이다?

 

아래 정리는 MDN web docs(가 RFC를 근거로 작성한 문서)와 wiki(에서 RFC를 근거로 작성한 문서)를 섞은 내용이다.

 

1. GET: 리소스 조회

2. POST: 요청 데이터 처리, 주로 등록에 사용

3. PUT: 리소스 전부 교체

4. PATCH: 리소스 일부분 변경

5. DELETE: 리소스 삭제

 

6. HEAD: GET 요청했을 때 돌아올 헤더를 요청

7. CONNECT: 요청 리소스에 대해 양방향 연결을 시작하는 메서드

8. OPTIONS: 주어진 URL 또는 서버에 대해 허용된 통신 옵션을 요청

9. TRACE: 타겟 리소스의 경로를 따라 메시지 loop-back 테스트

6~9는 짧은 소개로 이해가 어려우니 문서를 참고하자.

HTTP 요청 메서드 - HTTP | MDN

 

https://ko.wikipedia.org/wiki/HTTP

 

 

2. 결론

사실 공식문서에 있는 내용을 읽고 공부하는 데에 의미가 있었고,

앞으로도 참고해야 한다면 공식문서를 볼 거 같다 (이 글 말고ㅎ;)

 

그래도 각 HTTP Method마다 스펙이 존재한다는 사실~

그리고 Request body 여부나 successful response has body나 cacheable 등이 다 규약이 있다는 게 재밌기도 하다.

참고해서 프로젝트에 적용해보도록 하자~