You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There have been some discussions about whether further describing a potential HTTP request with an Operation type violates REST's uniform interface constraint:
On Feb 3, 2014, at 3:19 PM, Markus Lanthaler wrote:
On Friday, January 31, 2014 4:50 PM, Ryan J. McDonough wrote:
On Jan 30, 2014, at 9:20 AM, Mark Baker wrote:
Our last discussion failed, but this discussion on Ryan's excellent
points seems to have drilled down to a bite sized point that I'll
offer a quick observation on...
On Tue, Jan 28, 2014 at 7:45 AM, Markus Lanthaler wrote:
Yeah, DELETE is very specific and it might look as if it doesn't
have any value. There exist, however, APIs that archive resources
that are being deleted. In such a case, I think it does make sense
to qualify a DELETE with an ArchiveOperation or something similar.
Basically the operation tells the client what kind of consequences
it can expect if it invokes an operation.
What you describe there is not REST. With REST, the client only knows
that a DELETE was performed upon receiving a 200 response, not that a
DELETE was performed along with some other stuff that is indicated
separately (either in-band in the message, or out-of-band via
information received in a prior interaction). Just DELETE, as
defined in the HTTP spec.
Right. That's the contract. But AFAICT that doesn't mean that it is a
violation of any of REST's constraints to give a client more information
that it can use to choose which of the potential requests it might wanna
make.
Do you disagree?
This is a central pillar of Hydra's design and should be further discussed.
The text was updated successfully, but these errors were encountered:
PROPOSAL: Operations are hypermedia controls and as such do not violate any of REST's constraints. When the specification will be restructured to talk about things affecting the application state (links) and things affecting the resource state (operations) this will hopefully become clearer (see ISSUE #44). In general, the intent is to write the spec mostly from a client's point of view.
There have been some discussions about whether further describing a potential HTTP request with an
Operation
type violates REST's uniform interface constraint:On Feb 3, 2014, at 3:19 PM, Markus Lanthaler wrote:
This is a central pillar of Hydra's design and should be further discussed.
The text was updated successfully, but these errors were encountered: