Closed lanthaler closed 5 years ago
+1 :wink:
PROPOSAL: Restructure the specification to talk about application state (navigation, etc.), resource state (manipulation of resources on the server), and the API as a whole (metadata, domain vocabulary etc.). This will then also describe why, e.g., there's no GetResourceOperation.
I'd volunteer for (helping with) restructuring the spec in that way during summer. (Not adding this to the mailing list thread because it's not about content.)
Awesome! Thanks a lot Ruben. Much appreciated.
:bell:
I hope that our further work on the spec will bring some changes demanded in this issue, but it will be a long term process. Let me close it for now so we can focus on more important tasks.
Label "obsolete" does not seem to be appropriate.
Might be, but we wanted to mark the issues we agreed on the call with a single label, and the obsolete
fit best to most of them.
Currently, the specification is written mostly from the perspective of the server side as the API publisher needs to create the Hydra descriptions. It may, however, make more sense to describe things from a client's perspective as that is where those descriptions are going to be used. That way it becomes simpler to justify why certain things should be done, what aspects are improved, and what functionality is enabled by doing so. Nothing is just described for the sake of it should always happen with a clear purpose in mind.
Thus, the specification should probably be restructured to talk about application state (navigation, etc.), resource state (manipulation of resources on the server), and the API as a whole (metadata, domain vocabulary etc.). This will then also describe why, e.g., there's no
GetResourceOperation
.