JUST WRITE

GET vs POST 본문

Network

GET vs POST

천재보단범재 2021. 9. 22. 16:20

GET vs POST

HTTP Protocol로 Client에서 Server로 요청할 때 방식을 HTTP 요청 Method(RFC7231_명세)라고 정의합니다.

HTTP Request Message 가장 첫번째 줄에 위치합니다.

GET /dir/page.html HTTP/1.1

GET, HEAD, POST ... 등 다양한 방식이 있습니다.

이번 글에서는 가장 많이 이용되는 GET, POST 두 가지 방식에 대해 정리하려 합니다.

GET

GET 방식은 특정 리소스를 가져오도록 요청하는 메소드 방식입니다.

대표적인 특징인 URL에 Parameter가 포함되어 전송됩니다.

URL 뒤에 '?' 부분부터 Paramter 부분이 시작되고, '&'로 Paramter가 구분됩니다.

https://developnote-blog.tistory.com/manage/newpost/?type=post&returnURL=%2Fmanage

특징

  • 요청정보가 Request 본문이 아닌 URL에 존재
    • 요청 정보 전송 제한(URL 포함 255 bytes는 주의, Browser마다 제한 글자 수 다름)
    • 요청 정보가 Parameter에 노출되기 때문에 중요 정보라면 GET 방식 부적절
The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15).
Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths.
  • 읽기 전용 Method -> Server 상태를 직접적으로 바꾸지 않는다.
  • 캐시 가능(Cacheable, RFC7231_명세)

POST

POST 방식은 서버로 데이터를 전송하는 방식입니다.

데이터 유형은 Content-Type Header로 나타냅니다.

GET 방식과는 다르게 Request BODY 영역에 데이터를 넣어서 보냅니다.

[Header]
POST / HTTP/1.1
Host: foo.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 13

[Body]
say=Hi&to=Mom

특징

  • 요청정보가 Request Body에 있어 길이에 제한 X
  • Server에 전송한 데이터를 기반으로 Server에 변경사항을 만듦.
  • 캐시 불가능 -> 가능은 하지만 거의 구현되지 않음.

GET vs POST

항목 GET POST
Request Body 존재 X O
Response Body 존재 X O
안전함 O X
멱등성 O X
캐시 가능 O X

[참고사이트]

728x90
반응형

'Network' 카테고리의 다른 글

JWT  (0) 2021.12.10
Synchronous vs Asynchronous  (0) 2021.11.12
SSL  (0) 2021.09.18
HTTP vs HTTPS  (0) 2021.09.17
Session Clustering  (0) 2021.09.02
Comments