I posted the examples above into a discussion about how to send command messages to a domain model.
The domain model is the inner core of the onion. In particular, it shouldn't be directly coupled to HTTP.
The client sends one HTTP request to a single socket, and that the listener on that socked translates the HTTP Request into a message that the domain model understands. There's no particular advantage, from the point of view of the domain model, that some of the information is provided in the message body, and some in the headers, when it is all being transformed before it reaches the core domain logic.
Consider, for example, a form in a web page. It is a perfectly straight forward exercise to ensure that the application/x-www-form-urlencoded representation of the message is complete by adding a few hidden fields that the consumer doesn't need to worry about. When this is done, the particular URL used in the action really doesn't matter.
This is generally true: the resource identifier doesn't have to support the domain, because we have the message body for that.
The target resource identified by the request line becomes a free variable.
In HTTP, GET doesn't have a message body. When we request a resource from the server, any parameters that the server requires to discriminate between resources needs to be included in the identifier itself. Because HTTP is designed for large-grain hypermedia transfer, there are provisions for the server to provide to the client the appropriate caching semantics.
The real significance of the URI for POST is this -- it gives us the means to invalidate the representations of a specific resource from the client's cache.
No comments:
Post a Comment