HTTP 완벽가이드 스터디 #3 HTTP 메시지

이번 포스팅에서는 HTTP 완벽가이드 책을 활용하였습니다.

3장 HTTP 메시지

HTTP 메시지는 HTTP 애플리케이션간에 주고받는 데이터의 블록이다.

모든 HTTP 메시지는 요청 메시지나 응답 메시지로 분류된다. 

이번에도 HTTP method 까지의 내용을 코드로 구현해보았다. 

 

> https://github.com/brainbackdoor/bbd-http-web/blob/master/docs/message/README.md

brainbackdoor/bbd-http-web

추가적으로, 

- 흔히 알고 있는 RESTful에서의 POST와 PUT 역할이 이 책의 가이드와 다르다. (보통 PUT은 수정, POST는 생성으로 많이 사용)
   PUT은 URI가 존재하면 update 없으면 insert를 한다.
   POST는 URI가 collection일 경우 collection에 추가하고 element일 경우 해당 URI를 collection으로 간주하여 그 하위에 들어간다.

   즉, PUT을 사용하여 리소스를 생성할 경우, 요청하는 쪽에서 ID를 알고 있어야 한다.
   POST로 생성을 하려면 ID를 모르는 상태에서 URI에 collection을 지정해야 한다.
   ex) "PUT /articles/1" 하면 1번 글이 생성되고, "POST /articles" 하면 서버에서 할당한 번호의 글이 생성된다.

 

---

HTTP Status 비교

> https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

 

>https://tools.ietf.org/html/rfc2616#section-10

 

서비스별 HTTP Status 정리 자료

> https://gist.github.com/vkostyukov/32c84c0c01789425c29a

 

> https://www.restapitutorial.com/httpstatuscodes.html

HTTP Status Codes

# 200 vs 201

 

   200 응답의 경우,

   GET요청 된 자원에 대응하는 엔티티가 응답으로 전송되고, HEAD 요청 된 자원에 해당하는 엔티티 헤더 필드는 메시지 본문없이 응답을 전송한다. 
   POST 요청의 경우 조치 결과를 설명하거나 포함하는 엔티티를 전송하며, TRACE 요청의 경우 최종 서버가 수신한 요청메시지를 엔티티에 포함하여 응답한다.

   

   반면, 201 응답의 경우, Location Header field에 구체적인 URI를 작성하여 응답해야 한다. 엔티티 형식은 Content-Type에 따라 달라지며, 조치를 즉시 수행할 수 없는 경우 202 (Accepted)로 답해야 한다. 

> https://stackoverflow.com/questions/1860645/create-request-with-post-which-response-codes-200-or-201-and-content 

 

# 204 vs 404

 

   204 응답의 경우, 엔티티 본문을 리턴할 필요가 없는 경우에 사용한다. (삭제 등)

   404 응답의 경우, 호스팅 서버에서 요청시 리소스(page)가 없는 경우에 사용된다.

> https://stackoverflow.com/questions/34312023/http-get-request-status-204-vs-404

HTTP GET Request Status 204 Vs 404

# 400 vs 422

 

  400 응답의 경우, 요청 메시지의 syntax, 권한 등이 유효하지 않아 서버에서 이해할 수 없는 경우에 사용한다.

  422 응답의 경우, Entity의 Content-Type을 서버에서 이해할 수는 있으나, 담긴 데이터의 필드 등이 유효하지 않은 경우에 사용된다.

> https://stackoverflow.com/questions/16133923/400-vs-422-response-to-post-of-data

400 vs 422 response to POST of data

# 301 vs 302 vs 303 vs 307

// Redirect 301.
 
response.setStatus(HttpServletResponse.SC_MOVED_PERMANENTLY);
response.setHeader("Location", newUrl);
 
 
// Temporary Redirect (Redirect 302)
response.sendRedirect(newURL);

  301 응답은 Client단에 정보를 남겨 cookie가 남아있는한 설정된 URL로 연결된다. 영구적인 Redirection을 의미하며, cookie가 사라질 경우 후속요청을 하는 클라이언트는 새로운 URI를 사용해야 한다. Location 헤더에 현재 리소스가 존재하고 있는 URL을 포함해야 한다.

  302 응답은 서버에 웹 페이지 요청시 다른 URL로 연결시키며, 임시로 가리키기 위한 목적으로 사용해야 한다. 이 후의 요청은 원래 URL을 사용해야 한다.

  303 응답은 리소스가 다른 URI에 있으나 GET 메서드를 사용해서 (Location 헤더에 주어진 리소스를) 얻어야 한다는 것을 명시적으로 나타낸다.

  307 응답은 302와 동작방식이 같지만, POST 등의 요청도 POST 방식으로 redirect한다는 차이가 있다.

> https://stackoverflow.com/questions/4764297/difference-between-http-redirect-codes

Difference between HTTP redirect codes

---

- HTTP 응답과정 다이어그램

> https://github.com/for-GET/http-decision-diagram

 

- HTTP Header 

> https://www.iana.org/assignments/message-headers/message-headers.xhtml

 

---

추가적으로, RequestMapping에 Method를 설정하지 않았을 시에 해당 URL에 대해 모든 Method로 요청할 수 있다. 특정 Method로 설정해두었을 경우 그 외의 Method로 요청시에는 405 로 응답한다.