HTTP Method의 스펙

2023. 6. 28. 23:20· 코딩/WEB 개발
목차
  1. 0. 서론
  2. 1. 본론
  3. 1-1. IETF RFC
  4. 2. 결론

0. 서론

식스펙

 

HTTP 요청 메서드 - HTTP | MDN

HTTP는 요청 메서드를 정의하여, 주어진 리소스에 수행하길 원하는 행동을 나타냅니다. 간혹 요청 메서드를 "HTTP 동사"라고 부르기도 합니다. 각각의 메서드는 서로 다른 의미를 구현하지만, 일부

developer.mozilla.org

 

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

HTTP는 요청 메서드를 정의하여, 주어진 리소스에 수행하길 원하는 행동을 나타냅니다. 간혹 요청 메서드를 "HTTP 동사"라고 부르기도 합니다. 각각의 메서드는 서로 다른 의미를 구현하지만, 일부

developer.mozilla.org

 

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

 

 

2. 결론

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

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

 

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

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

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

 

저작자표시 비영리 (새창열림)

'코딩 > WEB 개발' 카테고리의 다른 글

Spring - RestTemplate vs. WebClient  (0) 2023.07.25
Spring - @PathVariable 에서 마지막 "~.com"이 짤리는 현상에 대해  (0) 2023.07.19
HTTP Method의 멱등성에 대해  (0) 2023.06.28
HTTP Method, PUT과 PATCH의 차이점  (0) 2023.06.28
동시 편집에 대해...  (0) 2023.06.19
  1. 0. 서론
  2. 1. 본론
  3. 1-1. IETF RFC
  4. 2. 결론
'코딩/WEB 개발' 카테고리의 다른 글
  • Spring - RestTemplate vs. WebClient
  • Spring - @PathVariable 에서 마지막 "~.com"이 짤리는 현상에 대해
  • HTTP Method의 멱등성에 대해
  • HTTP Method, PUT과 PATCH의 차이점
승농
승농
나는 실시간으로 강해지고 있는 백엔드 개발자.
승농
개발자국의 승농
승농
전체
오늘
어제
  • 분류 전체보기 (57)
    • 자유 (0)
    • 코딩 (33)
      • Java (15)
      • WEB 개발 (14)
      • Kotlin (1)
      • DB (1)
    • PS - CodeUp (9)
    • PS - BOJ (15)

블로그 메뉴

  • 블로그 소개
  • 방명록

공지사항

인기 글

관리자

최근 댓글

최근 글

hELLO · Designed By 정상우.v4.2.0
승농
HTTP Method의 스펙
상단으로

티스토리툴바

개인정보

  • 티스토리 홈
  • 포럼
  • 로그인

단축키

내 블로그

내 블로그 - 관리자 홈 전환
Q
Q
새 글 쓰기
W
W

블로그 게시글

글 수정 (권한 있는 경우)
E
E
댓글 영역으로 이동
C
C

모든 영역

이 페이지의 URL 복사
S
S
맨 위로 이동
T
T
티스토리 홈 이동
H
H
단축키 안내
Shift + /
⇧ + /

* 단축키는 한글/영문 대소문자로 이용 가능하며, 티스토리 기본 도메인에서만 동작합니다.