[Network] HTTP Method

REST는 프로토콜이나 표준이 아닌 아키텍처 원칙 세트이다.  API 개발자는 REST를 다양한 방식으로 구현 가능하다.

 

 RESTful API는 다음 기준을 따라야 한다. 

모든 리소스를 URI로 구별할 수 있다
모든 리소스는 복수의 형태로 나타낼 수 있다
모든 리소스는 HTTP 표준 메소드를 이용하여 접근/수정/생성/삭제할 수 있다

클라이언트, 서버 및 리소스로 구성되었으며 요청이 HTTP를 통해 관리되는 클라이언트-서버 아키텍처

스테이트리스(stateless) 클라이언트-서버 커뮤니케이션: 요청 간에 클라이언트 정보가 저장되지 않으며, 각 요청이 분리되어 있고 서로 연결되어 있지 않음

 

HTTP 요청 메서드

GET : GET 메서드는 특정 리소스의 표시를 요청합니다. GET을 사용하는 요청은 오직 데이터를 받기만 함.
HEAD : HEAD 메서드는 GET 메서드의 요청과 동일한 응답을 요구하지만, 응답 본문을 포함안 함.
POST : POST 메서드는 특정 리소스에 엔티티를 제출할 때 사용.
PUT : PUT 메서드는 목적 리소스 모든 현재 표시를 요청 payload로 변경
DELETE : DELETE 메서드는 특정 리소스를 삭제.
CONNECT : 프락시 서버와 같은 중간 서버 경유.
OPTIONS :  웹서버측 제공 메소드에 대한 질의 - 가능한 메소드 옵션에 대한 질의.
TRACE : 요청 리소스가 수신되는 경로를 보여줌.
PATCH : PATCH 메서드는 리소스의 부분만을 수정.

 

RESTful API용 HTTP 메소드 요약

메소드	CRUD	전체 컬렉션	특정 항목
POST	Create	201 (Created), ‘Location’ header with link to /users/{id} containing new ID.	Avoid using POST on single resource
GET	Read	200 (OK), list of users. Use pagination, sorting and filtering to navigate big lists.	200 (OK), single user. 404 (Not Found), if ID not found or invalid.
PUT	Update/Replace	405 (Method not allowed), unless you want to update every resource in the entire collection of resource.	200 (OK) or 204 (No Content). Use 404 (Not Found), if ID not found or invalid.
PATCH	Partial Update/Modify	405 (Method not allowed), unless you want to modify the collection itself.	200 (OK) or 204 (No Content). Use 404 (Not Found), if ID not found or invalid.
DELETE	Delete	405 (Method not allowed), unless you want to delete the whole collection — use with caution.	200 (OK). 404 (Not Found), if ID not found or invalid.

 

GET방식과 POST방식 비교

BACK button/Reload	Harmless	Data will be re-submitted (the browser should alert the user that the data are about to be re-submitted)
Bookmarked	Can be bookmarked	Cannot be bookmarked
Cached	Can be cached	Not cached
Encoding type	application/x-www-form-urlencoded	application/x-www-form-urlencoded or multipart/form-data. Use multipart encoding for binary data
History	Parameters remain in browser history	Parameters are not saved in browser history
Restrictions on data length	Yes, when sending data, the GET method adds the data to the URL; and the length of a URL is limited (maximum URL length is 2048 characters)	No restrictions
Restrictions on data type	Only ASCII characters allowed	No restrictions. Binary data is also allowed
Security	GET is less secure compared to POST because data sent is part of the URL Never use GET when sending passwords or other sensitive information!	POST is a little safer than GET because the parameters are not stored in browser history or in web server logs
Visibility	Data is visible to everyone in the URL	Data is not displayed in the URL

 

HTTP 요청 메서드별 속성

멱등성 
동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니고, 서버의 상태도 동일하게 남을 때, 해당 HTTP 메서드가 멱등성을 가졌다고 말합니다. 멱등성 메서드에는 통계 기록 등을 제외하면 어떠한 부수 효과(side effect)도 존재해서는 안됩니다. 올바르게 구현한 경우 GET, HEAD, PUT, DELETE 메서드는 멱등성을 가지며, POST 메서드는 그렇지 않습니다. 모든 안전한 메서드는 멱등성도 가집니다.

안정성
HTTP는 안전한 메서드라 불리는 메서드의 집합이다.
안전한 메서드의 목적은 서버에 어떤 영향을 줄 수 있는 안전하지 않은 메서드가 사용될 때 사용자들에게 그 사실을 알려줄 수 있도록 하는 것이다.

캐시 가능성
향후 재사용을 위해 이에 대한 응답을 저장할 수 있음을 나타낸다.

메소드명	안정성	멱등성	캐시가능성
GET	O	O	O
POST	X	X	X
PUT	X	O	X
DELETE	X	O	X

---

참고 사이트 

https://www.redhat.com/ko/topics/api/what-is-a-rest-api

https://developer.mozilla.org/ko/docs/Web/HTTP/Methods

https://restfulapi.net/http-methods/

http://www.ktword.co.kr/test/view/view.php?m_temp1=3791 

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