[
Lists Home |
Date Index |
Thread Index
]
Rich Salz wrote:
>>>You've doubled the reliability, security, and server-state load,
>>>but it is RESTian. For many applications that won't be enough.
>>
>>Where do you get the factor of two from?
>
> Twice the number of HTTP messages, nothing more simple then that.
Fair enough, although not in all cases.
For the example we were discussing (searching) an application is likely
to immediately GET the url to view the results.
In *other* applications of the same message pattern, there's requirement
for the client-side application to immediately follow the Location
header and perform a GET:
* If a new resource is being created, then a client may be sufficiently
happy that its received a redirect(*) rather than an HTTP status code.
A GET on the new URI may be redundant as it'll echo back the data I
just sent the server. So one message and a cheap response
* In other scenarios a client may choose to perform the GET in a few
minutes time, or next week. So the pattern supports asynchronous usage
which is handy. (The server may not actually carry out the original
request until the GET is issued, so this pattern can be properly
asynchronous)
* The client may actually issue a conditional GET which results in
smaller server responses, so again it can be efficent.
So I accept that yes there are 2 messages, but there's a lot of
variables to consider and options available. I'm not sure I see those
same options with a "POST to controller; return response" approach.
> As for server-state, the server now has to maintain state behind
> the GET'able URL, make sure that it's the same client coming back
> or otherwise deal with authorization decisions, etc.
Whether its inconvenient for the server to maintain state depends on
whether the results of the POST are the creation of domain objects --
these will have their own lifetime and are likely to be maintained
anyway. So there's no real difference between the approaches there.
For the search example, keeping track of what searches a user has
performed may or may not be a significant factor for the application.
But recall that we were talking about a healthcare application. If the
result is a single hit, i.e. I've found the relevant patient, then
the returned URL is just that of the patient (i.e. the domain objects)
so no additional state management required.
Re: authorization decisions. It's no harder to protect, say /* with
an authentication filter than /controller, so I don't see any
difficulties there.
So the answer, as usual, is "it depends". But I thought it worth
responding as I wanted to challenge the assertion that REST message
patterns are automatically less efficient, harder to protect, etc. As
ever application design trade-offs come into play, but as I've noted
above I see more options with a REST style approach.
(*) in this thread I've kept writing 302, when in some cases I ought to
have suggested use of 303 See Other. Apologies.
Cheers,
L.
|
