프로토콜이란 양자간에 미리 정한 약속, 규약이다. A 가 “아”라고 보내면 B 는 그것을 “아버지”로 이해하도록 약속을 정했다면 그것이 바로 프로토콜이다.
인터넷 프로토콜을 정의하는 기구는 IETF 라는 단체이며 누군가가 문서를 제출하면 검증되기 전까지는 draft 형태로 존재하다가 여러 사람이 검증하여 표준으로 채택되면 RFC 라는 표준 문서로 승격되게 된다.
Http 프로토콜
HTTP 프로토콜은 RFC2616 에 정의되어있다.
HTTP 메시지 프로토콜은 반드시 request/response 의 한쌍으로 구성되어있다. 그리고 request와 response 는 각각 header 와 body 로 이루어져 있고 header와 body 사이에는 반드시 한줄이 띄어져야 한다.
이 부분이 http 프로토콜의 장점이자 단점이다. http는 반드시 먼저 요청해야만 받을수 있기 때문에, 카카오톡과 같이 서버로부터 데이터를 먼저 받는 것은 불가능하므로, 먼저 받기 위해서는 FCM 푸쉬나 소켓통신을 통해서 해결해야 한다.
http method
http method는 request 헤더의 첫번째 줄 첫번째에 명시되어있다.
method의 정의는 RFC2616 5.1.1에 설명되어있다. http uri가 리소스에게 수행하는 방법 이라고 되어있다.
method의 종류, 즉 리소스에 수행할 방법으로는 GET, POST, PUT, DELETE, OPTIONS, PATCH 등 여러가지가 존재한다. GET은 리소스를 가져오겠다는 의미로, POST는 리소스에 데이터를 게시하겠다는 의미로, PUT은 리소스의 특정 부분을 수정하겠다는 의미로, DELETE는 리소스를 삭제하겠다는 의미로 정의되어있다.
그래서, GET, POST, PUT, DELETE 이 4가지 method로 DB와 같은 리소스에 대해서 CRUD가 가능하므로 이 4가지를 조합해서 REST api를 만들어서 사용하고 있다. 그렇지만 REST api는 표준 프로토콜이 아니라 http 의 특정 메서드를 활용한 것에 불과하다는것을 명심해야 한다.
content type
헤더부분에 명시된 content type은 body의 데어타가 어떤 타입인지를 명시한다.
그러므로, content type은 request에도 명시될 수 있고, response 시에도 명시될 수 있다.
html에서 form 방식으로 전송되는 데이터 타입은 x-www-form-url-encoded 방식이다. key=value&key2=value2 이런 형식으로 전송되는 타입이다.
json 형태로 보낼때는 application/json 타입으로 정의한다.
status code
상태코드는 response 의 첫번째 줄 첫번째에 명시되어있다.
RFC2616 문서의 6.1.1 에 정의되어있다. 개발시에 상태코드를 보면 무슨 문제인지를 알 수 있어야 한다. 왜냐하면 상태코드가 오류가 나면 대부분 개발자 코드에 찍히는게 아니라 브라우저가 에러를 처리하기 때문이다.
따라서 4xx 번대 에러는 반드시 알고 있어야 한다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
"200" : OK "201" : Created "400" : Bad Request "401" : Unauthorized "402" : Payment Required "403" : Forbidden "404" : Not Found "405" : Method Not Allowed "406" : Not Acceptable "407" : Proxy Authentication Required "408" : Request Time-out "409" : Conflict "410" : Gone "411" : Length Required "412" : Precondition Failed "413" : Request Entity Too Large "414" : Request-URI Too Large "415" : Unsupported Media Type "500" : Internal Server Error |