search

HydraCG / Specifications

Specifications created by the Hydra W3C Community Group
Other
139 stars 25 forks source link

Clarify relationship between Hydra operations and OPTIONS request #10

Closed dschulten closed 10 years ago

dschulten commented 10 years ago

Hydra operations seem to duplicate an OPTIONS request. Do we really need them? If so, the need should be justified. Right now my feeling is, they should be dropped.

lanthaler commented 10 years ago

Dietrich Schulten raised the following an issue on GitHub [1]:

Hydra operations seem to duplicate an OPTIONS request. Do we really need them? If so, the need should be justified. Right now my feeling is, they should be dropped.

I will respond to the mailing list because most people won't see the issue on GitHub.

The HTTP OPTIONS method is a method and just that. It still needs some kind of description to return or you could also just stick to the HTTP Allow header which tells you which methods are allowed (but you can include that header also in a GET). So, even if Hydra would use OPTIONS, it would still need operations to describe the semantics of an operation and the expected data.

Overall, I'm not a big fan of OPTIONS. It makes it difficult to link to the description. The responses are by definition not cacheable so you would have to repeat the request on every single interaction. Simply linking to a description or even better directly embedding the operations in a response is a much better approach.

Dietrich, I would like to hear how you think a solution based on OPTIONS (alone) could achieve the same as Hydra operations.

Cheers, Markus

[1] https://github.com/HydraCG/Specifications/issues/10

Markus Lanthaler @markuslanthaler

lanthaler commented 10 years ago

As there has been no response for more than 8 months, I'm closing this issue now. @dschulten, if you would like to discuss this further, please re-open the issue and send a mail to the Hydra mailing list. Thanks