(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
Let’s talk in more detail about some of the basic HTTP methods, listed earlier in Table 3-1.
Table 3-1에 나왔던 몇 가지 HTTP 메소드에 대해 더 자세히 이야기해봅시다.
** [1] GET과 [2] HEAD는 지지난 포스팅을, [3] PUT, [4] POST, [5] TRACE는 지난 포스팅을 참고해주시기 바랍니다.
The OPTIONS method asks the server to tell us about the various supported capabilities of the web server. You can ask a server about what methods it supports in general or for particular resources. (Some servers may support particular operations only on particular kinds of objects).
OPINIONS 메소드는 웹 서버가 지원하는 다양한 기능에 대해 알려줄 것을 서버에게 요청하는 것입니다.
여러분은 서버에게 일반적인 리소스 혹은 특정한 리소스에 어떤 메소드를 지원하는지 질문할 수 있습니다.
어떤 서버는 특정한 종류의 객체에만 특정 동작을 지원할지도 모릅니다.
This provides a means for client applications to determine how best to access various resources without actually having to access them. Figure 3-12 shows a request scenario using the OPTIONS method.
이것은 클라이언트 애플리케이션이 실제로 리소스에 접근하지 않고도 다양한 리소스를 접근하는 최선의 방식을 결정할 수 있게 합니다.
Figure 3-12는 OPTIONS 메소드를 활용한 요청 시나리오를 보여줍니다.
The DELETE method does just what you would think—it asks the server to delete the resources specified by the request URL. However, the client application is not guaranteed that the delete is carried out. This is because the HTTP specification allows the server to override the request without telling the client. Figure 3-13 shows an example of the DELETE method.
DELETE 메소드는 여러분이 생각한 그대로의 작업을 합니다. 이 메소드는 서버에게 요청 URL이 나타내는 리소스를 삭제할 것을 요청합니다.
그러나, 클라이언트 애플리케이션이 삭제가 수행되는 것을 보장하지는 않습니다.
HTTP 명세에 따라 서버가 클라이언트를 호출하지 않고 요청을 재정의할 수 있기 때문입니다.
Figure 3-13은 DELETE 메소드의 예시를 보여줍니다.
HTTP was designed to be field-extensible, so new features wouldn’t cause older software to fail. Extension methods are methods that are not defined in the HTTP/1.1 specification. They provide developers with a means of extending the capabilities of the HTTP services their servers implement on the resources that the servers manage. Some common examples of extension methods are listed in Table 3-5. These methods are all part of the WebDAV HTTP extension (see Chapter 19) that helps support publishing of web content to web servers over HTTP.
HTTP는 필드 확장이 가능하게 설계되었습니다. 따라서 새로운 기능이 오래된 소프트웨어에 장애를 발생시키는 일은 없을 겁니다.
확장 메소드란 HTTP/1.1의 명세에는 정의되지 않은 메소드를 뜻합니다.
그것은 개발자에게 서버가 관리중인 리소스에 대해 구현한 HTTP 서비스의 능력을 확장할 수 있는 수단을 제공합니다.
확장 메소드의 몇 가지 일반적인 예시는 Table 3-5에 나열되어 있습니다.
이러한 메소드들은 모두 WebDAV HTTP 확장의 일부입니다. (Chapter 19에 나옵니다) WebDAV HTTP 확장은 HTTP 위의 웹 서버에 웹 콘텐츠를 게시하는 것을 지원함을 의미합니다.
It’s important to note that not all extension methods are defined in a formal specification. If you define an extension method, it’s likely not to be understood by most HTTP applications. Likewise, it’s possible that your HTTP applications could run into extension methods being used by other applications that it does not understand.
여기서, 모든 확장 메소드가 공식 명세에 정의되어 있지는 않다는 것에 유의하는 것이 중요합니다.
확장 메소드를 정의할 때 대부분의 HTTP 애플리케이션이 이해하지 못할 가능성이 있습니다.
마찬가지로 여러분의 HTTP 애플리케이션이 다른 애플리케이션에서 사용되는 확장 메소드를 이해하지 못하고 충돌할 수도 있습니다.
In these cases, it is best to be tolerant of extension methods. Proxies should try to relay messages with unknown methods through to downstream servers if they are capable of doing that without breaking end-to-end behavior. Otherwise, they should respond with a 501 Not Implemented status code. Dealing with extension methods (and HTTP extensions in general) is best done with the old rule, “be conservative in what you send, be liberal in what you accept.”
이러한 경우 확장 메소드에 대해 관대한 것이 가장 좋습니다.
프록시는 가능하다면 엔드 투 엔드 동작을 유지하면서 미지의 메소드를 가진 메시지를 다운스트림 서버에 전달하기 위해 노력해야 합니다.
그렇지 않으면 501 Not Implemented 상태 코드를 응답해야 합니다.
확장 메소드(일반적으로 HTTP 확장)를 처리하는 것은 다음의 고전적인 규칙에 의해 가장 성공적으로 수행됩니다. - "송신은 보수적이게, 수신은 관대하게"
오늘로 3일에 걸친 Methods 파트를 마친다. 알고 있던 메소드 외에도 몇 가지 새로운 메소드들을 알게 됐다. 실전에서 이러한 메소드들이 얼마나 사용이 될지는 모르겠으나 이론만이라도 알고 있는 게 백 배 낫다. 원래 지식은 먹을수록 배가 부른 법이다.
부담스럽지 않은 분량으로 글을 읽으니 매일 포스팅을 올리는 것도 그리 어려운 일은 아닌 것 같다. 그런데 하루를 건너뛰면 이런 마음가짐조차 금세 사라져버릴 테니 정신을 바짝 차리는 게 좋겠다. 개강하고 나면 여유가 많이 없을지도 모른다. 지금부터 매일 짬내서 글을 읽고 쓰는 습관을 들여놔야겠다.