HTTP 구조(Request + Response) / HTTP Method 특징 (PATCH vs PUT) / 자주 쓰이는 HTTP Status Code

Benjamin·2022년 9월 11일
0

CS

목록 보기
2/10

HTTP

HyperText Transfer Protocol

  • 하이퍼텍스트(HTML)문서를 교환하기 위해 만들어진 프로토콜
  • 웹상에서 네트워크로 서버끼리 통신할 때, 어떠한 형식으로 서로 통신하자고 규정해놓은 통신 구조
    -> 프론트엔드 서버와 클라이언트간 통신에 사용
    -> 백엔드와 프론트엔드 서버간 통신에도 사용

HTTP 통신방식

  • 요청/응답(request/response)구조
    클라이언트가 HTTP request를 서버에 보내면, 서버는 HTTP response를 보내는 구조
    클라이언트와 서버의 모든 통신이 요청과 응답으로 이루어진다.
  • stateless
    상태를 저장하지 않는다
    요청이 오면 그에 응답할 뿐, 여러 요청/응답끼리 연결되어있지 않다.
    즉, 각각의 요청/응답은 독립적인 요청/응답이다.
    예 ) 클라이언트가 요청을 보내고 응답을 받은 후, 조금 있다가 다시 요청을 보낼 때, 전에 보낸 요청/응답에 대해 알지 못한다.
    -> 만일 여러 요청/응답의 진행과정이나 데이터가 필요할 때에는 쿠키나 세션 등을 사용한다.

HTTP Request 구조

HTTP request 메시지는 크게 3부분으로 구성된다.

  • start line
  • headers
  • body

Start Line

HTTP Request의 첫 라인
이 또한 3부분으로 구성되어있다.

  • HTTP Method
    request가 의도한 action을 정의하는 부분
    GET, POST, PUT, DELETE, OPTIONS ...
  • Request target
    request가 전송되는 목표 uri
  • HTTP Version
    사용되는 HTTP 버전

Headers

  • request에 대한 추가정보를 담고있는 부분
    예) request 메시지 body의 총 길이 (Content-Length) ...
  • Key:value 값으로 되어있다
  • 이것도 3부분(general headers, request headers, entity headers)으로 나뉘지만, 너무 자세한 부분임으로 3부분으로 구성되어있다는것만 알고있어도 괜찮다.
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Type: application/json
Content-Length: 257
Host: google.com
User-Agent: HTTPie/0.9.3

자주 사용되는 headers정보

  • Host
    요청이 전송되는 target의 host url
  • User-Agent
    요청을 보내는 클라이언트에 대한 정보
  • Accept
    해당 요청이 받을 수 있는 응답 타입
  • Connection
    해당 요청이 끝난 후, 클라이언트와 서버가 계속해서 네트워크 커넥션을 유지할것인지 끊을것인지에 대해 지시하는 부분
  • Content-Type
    해당 요청이 보내는 메시지 body 타입
  • Content-Length
    메시지 body길이

Body

해당 request의 실제 메시지/내용
body가 없는 request도 많다.
예) GET request는 body가 없다.

POST /payment-sync HTTP/1.1

Accept: application/json
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 83
Content-Type: application/json
Host: intropython.com
User-Agent: HTTPie/0.9.3

{
    "imp_uid": "imp_1234567890",
    "merchant_uid": "order_id_8237352",
    "status": "paid"
}

HTTP Response 구조

크게 3부분으로 구성

  • Status Line
  • Headers
  • Body

Status Line

Response의 상태를 간략히 나타내는 부분

  • HTTP 버전
  • Status code
    숫자형식의 응답상태 나타내는 코드
    예)200
  • Status text
    응답상태 간략하게 설명해주는 부분
    예) Not Found

HTTP/1.1 404 Not Found

Headers

Response headers와 동일
다만, response에서만 사용되는 header 값들이있다.
예)User-Agent대신 Server헤더가 사용된다.

Body

Response body와 일반적으로 동일
Request와 마찬가지로 데이터를 전송할 필요가 없을경우, body가 비어있다.


HTTP Methods

GET

Requset_URI에 붙여 서버에게 받고자 하는 정보를 요청한다.

예를들면 즐겨찾기에 추가된 구글 페이지를 요청해온다고 치자.

Query_Strings Parameters

https://www.google.co.kr/?gfe_rd=cr&ei=9uv5WKC5IrTf8AfQmJ3QCA
주소를 보면 ? 으로 url의 끝임을 알리고 요청할 데이터의 표현을 보여준다.

여기서 보면 key 와 value로 나타나있는데,

  • key: gfe_rd, ei
  • value: cr, 9uv5WKC5IrTf8AfQmJ3QCA
    이렇게 나뉘어져 있고 각 구분자는 &으로 표현한다.
    GET 메소드는 URL에 특정 리소스를 붙여서 정보를 요청하는 메소드이며, 용량에 한계가 있기때문에 GET 요청시 Request Body 에 담아서 보내지 않는다. (가능하나 그렇게 쓰라고 만든 메소드가아님.)

POST

GET과는 다르게 URL로 보내지 않고 Reqeust body에 담아서 보낸다.

여기서 body에 담긴 내용물이 어떤 타입인지 보내야할때, 헤더에 다음과 같은 내용을 담는다.

Content-Type

Content-type에는 수많은 타입이 존재하지만 대표적인 것으로는 다음과같다.

//text
Content-Type: text/plain
Content-Type: text/css
Content-Type: text/html

//application
Content-Type: Application/json 
Content-Type: Application/x-www-form-urlencode
Content-Type: multipart/formed-data  //주로 파일 전송에 씀

바디에는 주로 서버에 전달하기에 비교적 가벼운 JSON을 담아 전달한다.

POST /auth/login HTTP/1.1
/* 생략 */
Content-Type: application/json

{
  "email": "json@gmail.com"
  "password": "votmdnjem12"
}

OPTIONS

주로 요청 URI에서 사용할 수 있는 method를 받아올 때 사용
예) 어떠한 uri에서 어떤 method를 요청가능한지(GET? POST?)알고싶으면, 먼저 OPTIONS요청을 사용해서 확인한다.

http -v OPTIONS http://example.org

OPTIONS / HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 0
Host: example.org
User-Agent: HTTPie/0.9.3

HTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POST
Cache-Control: max-age=604800
Content-Length: 0
Date: Mon, 20 Aug 2018 08:37:45 GMT
Expires: Mon, 27 Aug 2018 08:37:45 GMT
Server: EOS (vny006/0450)

PUT

멱등적인 메소드인데, 새로운 리소스를 생성하거나, 대상 리소스가 존재한다면 데이터를 대체한다.

그렇기 때문에 정보를 변경하는데 주로 쓰이는 메소드이다.

알아두면 좋은 응답코드(Status Code)

  • 기존 리소스가 수정된 경우: 200 (OK)
  • 전송 성공 후 자원이 생성됬을 경우: 201 (Created)
  • 전송은 했지만 전송할 데이터가 없는 경우: 204 (No Content)

PATCH

PUT과 유사하지만 멱등성을 가지지 않아 동일한 요청에 다른 결과를 야기할 수 있다.

PATCH는 PUT과는 다르게 자원의 부분을 교체한다.
즉, 모든 필드를 불러오지 않아도 일부분의 필드만 작성하여 부분 교체가 가능하다.

DELETE

지정된 리소스를 서버에 삭제해달라고 요청


멱등성?
여러번 수행해도 결과가 같음을 의미한다.
HTTP 메소드를 예를 들자면, GET, PUT, DELETE는 같은 경로로 여러 번 호출해도 결과가 같다.
그러나 POST는 매 호출마다 새로운 데이터가 추가된다. 
따라서, POST 연산은 결과가 멱등(Idempotent)하지 않지만, PUT은 반복 수행해도 그 결과가 멱등(Idempotent)하다.
-> 동일한 요청을 여러번 보내도 결과 PUT은 동일한 결과값을 유지하는 반면 POST는 보낸 요청에 따라 리소스가 생성이 된다.

PUT vs. PATCH

PATCH와 PUT은 둘 다 데이터의 수정을 위한 method이다.
그렇다면 두가지는 어떤 차이점이 있을까?

PATCH, which is used to apply partial modifications to a resource

PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload

  • PUT 요청 시 요청을 일부분만 보낸 경우 나머지는 default 값으로 수정되는 게 원칙이므로 바뀌지 않는 속성도 모두 보내야 한다.
    (만약 전체가 아닌 일부만 전달할 경우, 전달한 필드외 모두 null 혹은 default 값처리되니 주의해야한다.)

예) PUT HTTP 메소드로 gildong 이라는 유저의 나이(age)를 15로 변경하고자 할때 
수정된 값만 보낼 경우, 보내지 않은 데이터는 null로 변경되어 버린다.

PUT /users/1
{
    "age": 15 
}

HTTP/1.1 200 OK
{
    "name": null,
    "age": 15
}

따라서, PUT 요청 시에는 아래와 같이 변경되지 않는 데이터도 모두 전달해야한다. 

PUT /users/1
{
    "name": "gildong"
    "age": 15
}

HTTP/1.1 200 OK
{
    "name": "gildong",
    "age": 15
}

그러나 PATCH를 이용하여  ‘age’만 변경하는 요청을 보내면,
새롭게 바뀐 부분만 반영되며 나머지는 기존의 데이터가 유지된다.

PATCH /users/1
{
	"age": 15
}

HTTP/1.1 200 OK
{
	"name": "gildong",
	"age": 15
}

따라서, 자원의 일부를 수정할 때는 PATCH를, 전체적인 수정이 필요할 때는 PUT을 이용하는 것이 적절하다.


자주 쓰이는 HTTP Status Code

200 OK

가장 자주 보게 되는 status code.
문제없이 다 잘 실행 되었을때 보내는 코드.

301 Moved Permanently

해당 URI가 다른 주소로 바뀌었을때 보내는 코드.
HTTP/1.1 301 Moved Permanently

400 Bad Request

해당 요청이 잘못된 요청일때 보내는 코드.
주로 요청에 포함된 input 값들이 잘못된 값들이 보내졌을때 사용되는 코드.
예를 들어, 전화번호를 보내야 되는데 text가 보내졌을때 등등.

401 Unauthorized

유저가 해당 요청을 진행 할려면 먼저 로그인을 하거나 회원 가입을 하거나 등등이 필요하다는것을 나타내려 할때 쓰이는 코드.

403 Forbidden

유저가 해당 요청에 대한 권한이 없다는 뜻.
예를 들어, 오직 과금을 한 유저만 볼 수 있는 데이터를 요청 했을때 등.

404 Not Found

요청된 uri가 존재 하지 않는다는 뜻.
http -v google.com/no-such-uri

500 Internal Server Error

서버에서 에러가 났을때 사용되는 코드.
API 개발을 하는 백앤드 개발자들이 싫어하는 코드.

참고
https://devuna.tistory.com/77
https://velog.io/@teddybearjung/HTTP-구조-및-핵심-요소
https://velog.io/@pixelstudio/HTTP-Method와-Body

0개의 댓글