HyperText Transfer Protocol
HTTP request 메시지는 크게 3부분으로 구성된다.
HTTP Request의 첫 라인
이 또한 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정보
해당 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"
}
크게 3부분으로 구성
Response의 상태를 간략히 나타내는 부분
HTTP/1.1 404 Not Found
Response headers와 동일
다만, response에서만 사용되는 header 값들이있다.
예)User-Agent대신 Server헤더가 사용된다.
Response body와 일반적으로 동일
Request와 마찬가지로 데이터를 전송할 필요가 없을경우, body가 비어있다.
Requset_URI에 붙여 서버에게 받고자 하는 정보를 요청한다.
예를들면 즐겨찾기에 추가된 구글 페이지를 요청해온다고 치자.
Query_Strings Parameters
https://www.google.co.kr/?gfe_rd=cr&ei=9uv5WKC5IrTf8AfQmJ3QCA
주소를 보면 ? 으로 url의 끝임을 알리고 요청할 데이터의 표현을 보여준다.
여기서 보면 key 와 value로 나타나있는데,
GET과는 다르게 URL로 보내지 않고 Reqeust body에 담아서 보낸다.
여기서 body에 담긴 내용물이 어떤 타입인지 보내야할때, 헤더에 다음과 같은 내용을 담는다.
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"
}
주로 요청 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과 유사하지만 멱등성을 가지지 않아 동일한 요청에 다른 결과를 야기할 수 있다.
PATCH는 PUT과는 다르게 자원의 부분을 교체한다.
즉, 모든 필드를 불러오지 않아도 일부분의 필드만 작성하여 부분 교체가 가능하다.
지정된 리소스를 서버에 삭제해달라고 요청
멱등성?
여러번 수행해도 결과가 같음을 의미한다.
HTTP 메소드를 예를 들자면, GET, PUT, DELETE는 같은 경로로 여러 번 호출해도 결과가 같다.
그러나 POST는 매 호출마다 새로운 데이터가 추가된다.
따라서, POST 연산은 결과가 멱등(Idempotent)하지 않지만, PUT은 반복 수행해도 그 결과가 멱등(Idempotent)하다.
-> 동일한 요청을 여러번 보내도 결과 PUT은 동일한 결과값을 유지하는 반면 POST는 보낸 요청에 따라 리소스가 생성이 된다.
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 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을 이용하는 것이 적절하다.
가장 자주 보게 되는 status code.
문제없이 다 잘 실행 되었을때 보내는 코드.
해당 URI가 다른 주소로 바뀌었을때 보내는 코드.
HTTP/1.1 301 Moved Permanently
해당 요청이 잘못된 요청일때 보내는 코드.
주로 요청에 포함된 input 값들이 잘못된 값들이 보내졌을때 사용되는 코드.
예를 들어, 전화번호를 보내야 되는데 text가 보내졌을때 등등.
유저가 해당 요청을 진행 할려면 먼저 로그인을 하거나 회원 가입을 하거나 등등이 필요하다는것을 나타내려 할때 쓰이는 코드.
유저가 해당 요청에 대한 권한이 없다는 뜻.
예를 들어, 오직 과금을 한 유저만 볼 수 있는 데이터를 요청 했을때 등.
요청된 uri가 존재 하지 않는다는 뜻.
http -v google.com/no-such-uri
서버에서 에러가 났을때 사용되는 코드.
API 개발을 하는 백앤드 개발자들이 싫어하는 코드.
참고
https://devuna.tistory.com/77
https://velog.io/@teddybearjung/HTTP-구조-및-핵심-요소
https://velog.io/@pixelstudio/HTTP-Method와-Body