Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Are Operations violating REST's uniform interface constraint? #31

Closed
lanthaler opened this issue Feb 4, 2014 · 2 comments
Closed

Are Operations violating REST's uniform interface constraint? #31

lanthaler opened this issue Feb 4, 2014 · 2 comments
Labels
design legacy obsolete Marker for the issues closed as obsolete after 2019-01-07 Operation question

Comments

@lanthaler
Copy link
Member

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.

@lanthaler
Copy link
Member Author

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.

@alien-mcl alien-mcl added the obsolete Marker for the issues closed as obsolete after 2019-01-07 label Jan 7, 2019
@alien-mcl
Copy link
Member

The proposal by @lanthaler is fair enough. I believe we can close it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design legacy obsolete Marker for the issues closed as obsolete after 2019-01-07 Operation question
Projects
None yet
Development

No branches or pull requests

2 participants