Re: ISSUE-31: Are Operations violating REST's uniform interface constraint? (was: More Thoughts on Links and Operation Subclasses)

On Thu, Feb 13, 2014 at 3:14 PM, Markus Lanthaler
<markus.lanthaler@gmx.net> wrote:
>> So a client consuming a Hydra description and recognizing the "Clear"
>> operation would know things that, for example, an HTTP proxy wouldn't
>> know by only understanding the DELETE operation.
>
> Yeah, even though here the knowledge would be quite limited (it knows that
> he *likely* won't get a 404 if he GETs the resource immediately after)
>
>
>> It might choose, for
>> example, to dispense with any error checking for 4xx since it knows
>> that after a successful DELETE/Clear, that it will get back a blank
>> page.
>
> Here you lose me. Why should it stop 4xx-error checking after a successful
> DELETE/Clear? To make this crystal clear, are you saying
>
>   - the client invokes the DELETE/Clear
>   - checks the status code of the response
>
> and *then* stops to check for 4xx errors? Why should it do so? What would it
> do then if it tries to dereference such a resource and get a 404? Would it
> break in a way it wouldn't otherwise?

Sorry, I see I wasn't totally clear in my description of the message
flow. The flow I had in mind was;

- client invokes DELETE/Clear
- client receives 200 response
- client invokes GET on the same URI
- client does not need to check for 4xx because of the semantics of "Clear"

>> That is the loss of visibility I mentioned, and results from
>> extending the contract between client and server, rather than reusing
>> the existing one.
>
> I understand in principle what you mean (the proxy doesn't know as much as
> the client does) but can't see how that's a problem

I had a longer, more point-by-point response drafted to the rest of
this message, but re-reading through it, realize that I should have
just stopped you here, and mentioned that you don't have to see a
problem to acknowledge that it isn't REST. It should suffice that one
of REST's architectural properties has been found lacking to
demonstrate that the solution isn't RESTful as you now know that at
least one constraint that provides the property has been violated, and
that there are problems relative to a RESTful solution. You can look
for those problems if you want, but principled design tells us that
there's no need. It can, however, be very helpful in understanding
REST in-depth (I speak from experience).

Now, if you're ok with Hydra not being RESTful, that's another matter :)

Mark.

Received on Friday, 21 February 2014 05:46:43 UTC