[HTTP 완벽가이드] 3장 - HTTP 메세지

HTTP 메세지

• 시작줄은 어떤 메세지인지 서술하고, 헤더 블록은 속성을, 본문은 데이터를 담고있다.

[요청 메세지]

<메서드> <요청 url> <버전>

<헤더>

 

<엔터티 본문>

 

[응답 메세지]

<버전> <상태 코드> <사유 구절>

<헤더>

 

<엔터티 본문>

 

 

안전한 메서드

• HTTP는 안전한 메서드라 불리는 메서드의 집합이다.
• 안전한 메서드의 목적은,
  서버에 어떤 영향을 줄 수 있는 안전하지 않은 메서드가 사용될 때
  사용자들에게 그 사실을 알려줄 수 있도록 하는 것에 있다.
• 읽기 전용인 경우 안전한 메서드로 간주한다.

PUT

The 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
-- rfc7231

• 서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 자료를 만들거나,
• 이미 URL이 존재한다면, 본문을 사용해서 교체한다.

POST

• 서버에 입력 데이터를 전송하기 위해 설계되었다.
• request의 body 타입은 Content-Type 헤더(header)에 따라 결정된다.
• POST는 비멱등성을 갖는다. 같은 POST를 연속적으로 보낸다면 명령을 여러 번 내린 것처럼 부가적인 효과를 가져올 것입니다.

RESTful 설계에서, 대개 하위 리소스를 생성할 때 POST를 사용한다. 이 리소스는 다른 "부모"리소스와 관계를 가진다.

웹로그 프로그램에서 각 웹로그 리소스는 "/weblogs/myweblog"와 같다. 그리고 각각의 웹로그 엔트리들은 부수적인 리소스로 "/weblogs/myweblog/1"과 같을 것이다.

출처: https://greatkim91.tistory.com/14 [행복한 아빠:티스토리]

멱등성

동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니고, 서버의 상태도 동일하게 남을 때, 해당 HTTP 메서드가 멱등성을 가졌다고 말합니다. 다른 말로는, 멱등성 메서드에는 통계 기록 등을 제외하면 어떠한 부수 효과(side effect)도 존재해서는 안됩니다. 올바르게 구현한 경우 GET, HEAD, PUT, DELETE 메서드는 멱등성을 가지며, POST 메서드는 그렇지 않습니다. 모든 안전한 메서드는 멱등성도 가집니다.

 

PUT 과 POST 의 차이점?

POST /posts -> 게시글을 생성한다. 게시글 id를 DB에 의해 자동 생성된다

PUT /posts/{id}  -> 해당 게시글 수정.

PUT /students/{studentId}

PUT과 POST의 차이점은 다음과 같다. 새로운 리소스의 URI가 클라이언트에 의해 결정될 경우 PUT을 사용한다. 새로운 리소스의 URI가 서버에 의해 결정될 경우 POST를 사용한다.

PUT을 사용하는 경우 클라이언트에서 서버에게 보내주는 정보(application state)로 새로운 리소스의 URI가 예측되고 결정된다. 즉 리소스의 대표이름(아이디나 키)이 클라이언트에 의해 결정된다.

반면 웹로그 프로그램의 경우를 보면, 클라이언트는 웹로그 엔트리 생성을 위해 필요한 정보를 알 수는 있다. 그러나 자원이 생성된 후 그 자원의 URI가 어떻게 될지 클라이언트는 알지 못한다.

아마 서버 기준으로 정렬을 기준으로 하거나 내부 데이터베이스 ID로 URI가 결정될 것이다. 최종 URI는 리소스가 추가되는 시점에 결정될 것이다. (/weblogs/myweblog/entiries/1 또는 /weblogs/myweblog/entries/1000 와 같이 1이나 1000은 서버 내부의 메커니즘에 의해 생성된다. 클라이언트는 이것을 결정할 수 없다.)

클라이언트는 서버가 언제 이 일을 하는지에 대해 알 필요가 없다.

출처)https://greatkim91.tistory.com/14

 

TRACE

- 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려준다. 주로 진단을 위해 사용되는데, 요청이 의도한 요청/응답 연쇄를 거쳐가는지, 프락시나 다른 애플리케이션들이 요청에 어떤 영향을 미치는지 확인.

- 하지만 중간 어플리케이션이 여러 다른요청을 일관되게 다룬다는 가정해야한다. 실제로는 메서드에 따라 HTTP 애플리케이션은 다르게 동작한다. ( POST 요청은 바로 서버로 통과시키지만, GET 요청은 웹캐시와 같은 다른 HTTP애플리케이션으로 전달한다)

상태 코드

100 - 199 정보성 상태 코드

 

[ 100 continue ]

클라이언트 애플리케이션이 서버에 엔티티 본문을 전송하기 전에 그 엔티티 본문을 서버가 받아들일것인지 확인하려고 할때, 그 확인 작업을 최적화 하기 위한 의도로 도입되었다.

 

클라이언트와 100 Continue

최적화를 위한 것. 서버가 다루거나 사용 할 수 없는 큰 엔티티를 서버에게 보내지 않으려는 목적으로 사용해야 한다.

클라이언트 개발자는 예상하지 못한 100 continue  응답에도 대비를 해야한다.