- From: Tomasz Pluskiewicz <tomasz@t-code.pl>
- Date: Mon, 14 Mar 2016 20:48:45 +0100
- To: Karol SzczepaĆski <karol.szczepanski@gmail.com>, public-hydra@w3.org
Hello Karol Thanks! >> 1. The server instructs the client what the actual payload is. Period. > So why it would need the payload to start with? If the payload is fixed, > don't bother the client with it and have an operation that doesn't > expect any body from the client - server will know it already. > Not that kind of fixed. More like fixed in the current circumstances. It's not the the operation doesn't expect any input. It's just the input is provided by the server. I realize that it could be done by URI with query string parameters but complex structures will be awkward in query parameters and also I don't feel like POST/PUT with empty body. >> 2. The server gives the initial representation, so that the client can >> fill the UI with default values > Well, smells like IriTemplate or MVC-like solution. > I achieve this with a complete data model description that is used to > build a UI form that is mapped to the underlying model which is a > resource created from scratch with "defaults" relative to it's > respective properties (or their ranges). Sound fine. Though I'm not convinced this is flexible enough. For one, the defaults could be context-specific. For example a data field is automatically set to current data plus some offset. Or some user-specific values are used and ApiDocumentation is not enough. > > I feel that IriTemplate may still be usable on simple cases (I'm not > sure on how to apply it to the body though), but in a more advanced > situation I'd stick with those MVC approaches. > That's why I stated that Hydra needs more generic approach when it come > describing what an operation expects or returns. +1 Regards, Tom
Received on Monday, 14 March 2016 19:49:17 UTC