- From: Tomasz Pluskiewicz via GitHub <sysbot+gh@w3.org>
- Date: Fri, 06 Jan 2023 11:13:55 +0000
- To: public-hydra-logs@w3.org
> ApiDocumentation being dynamic is just not something developers will expect. We may have a different expectation here, but that is one important difference which puts Hydra ahead of everyone else. The API Documentation can change over time... > as a template for which operations might become available We could accomplish that with OWL or SHACL by having a "computed class". For example. ```turtle </api/EditableArticle> a rdfs:Class, hydra:Class, sh:NodeShape ; rdfs:subClassOf </api/Article> ; sh:property [ sh:path schema:status ; sh:in ( </api/Draft> ) ; ] ; hydra:supportedOperation [ a schema:UpdateAction ; hydra:method "PUT" ; hydra:expects </api/Article> ; ] ; . ``` A resource representation would not need to be explicitly typed `</api/EditableArticle>` but instead a representation could be dynamically matched against that shape-class to determine whether that operation is allowed or not. A server could make that precomputation too, if desired, which would accommodate the authorization-dependent operation > Yes, Hydra Core needs a way to retract operations I am not convinced. Operation being additive are going to be much easier overall. -- GitHub Notification of comment by tpluscode Please view or discuss this issue at https://github.com/HydraCG/Specifications/pull/246#issuecomment-1373484296 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 6 January 2023 11:13:56 UTC