- From: Asbjørn Ulsberg <asbjorn@ulsberg.no>
- Date: Wed, 4 Nov 2015 12:56:38 +0100
- To: Tomasz Pluskiewicz <tomasz@t-code.pl>
- Cc: Markus Lanthaler <markus.lanthaler@gmx.net>, Hydra <public-hydra@w3.org>
2015-11-04 11:31 GMT+01:00 Tomasz Pluskiewicz <tomasz@t-code.pl>: >> How about the combination of a static hydra:ApiDocumentation and >> inline hydra:operation? Would the latter override the former? Is this >> described anywhere? > > This has been discussed in length before. Can you please point me to this discussion? > AFAIR, both descriptions are intended to be combined. The is no > overriding That's unfortunate. Do you remember the key arguments for this design decision? > But in light of the above, you would have to use 401 status codes. I find this problematic. Both because 401 relates to authentication and because the client needs to perform an extra request. I think 403 Forbidden or 405 Method Not Allowed are more suitable, but still think it should be possible for inline hydra:* to be able to override hydra:ApiDocumentation. > As an alternative, you could have client-side rules to be executed on > resources to determine whether a particular operation is allowed. I think that solution puts a huge burden on the clients, which is already pretty large due to the requirement of having full JSON-LD and Hydra processing capability. Because it is the "Code on demand" requirement of REST you're proposing as a solution here, right? -- Asbjørn Ulsberg -=|=- asbjorn@ulsberg.no «He's a loathsome offensive brute, yet I can't look away»
Received on Wednesday, 4 November 2015 11:57:06 UTC