- 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