Re: [Specifications] Retracting operations (#246)

> Thanks @asbjornu for detailed explanation. I'd love to deliberate more...
> 
> > One suggested way to deal with this is to not treat ApiDocumentation as a static resource, but instead re-request every time it changes.
> 
> It won't change anything - API documentation can be static resource that barely changes over time making a client effectively not re-requesting it. Also I don't see how re-requesting would help event if it changes - the operation in context may be unchanged at all.
> 
> > To treat out-of-bound metadata such as ApiDocumentation just as dynamic as the requested resource, however, is unintuitive. I don't think that's going to sit well with many developers.
> 
> I agree - I don't think we want to go this way.
> 
> > This means that auto-generated clients cannot make hydra:supportedOperation available on resource instances
> 
> I dare to disagree. As you've already noted, `hydra:supportedOperation` specifies an operation on the definition level - it's a way of extending a class with new features. If an instance of that very class, it must comply or it shouldn't be considered that class.
> 
> > instead, the operations are infrastructure that is used only when the hydra:operation in a response indicates that the operation should be available.
> 
> There would be no need for `hydra:supportedOperation` as inlined `hydra:operation` is fully sufficient. The `hydra:supportedOperation` was not mean to work like that and we won't change it in the spec - it would break everything in that matter that exists now.
> 
> @inf3rno, I was thinking about your statement:
> 
> > The upper is sort of query all except some. The other approach is query some. After adding NOT support, the next will be adding AND and OR support and more operators for comparison.
> 
> I don't think it has to do anything with querying. I'd stick to simple operations on sets (I believe set difference matches this case). Ok, matching operation may not be that simple (that's why I initially suggested direct operation IRI comparison), but it's doable event with simple clients.
> 
> Anyway, I seek for consensus on simple thing: do we need such a feature or shall we leave the clients with raw protocol responses - server will forbid an operation and the client will get to know about that sooner or later (later in this case)

Well what I was talking about that we have a set of available and not-available operations for each resource and each resource can have multiple types, which can have many supported operations. Normally we describe the resource types in the documentation, so we don't have to repeat this description countless times in our resources. For the actual resource we just give which types it has. After that if not all of the operations are available for the types, then we need to decide which ones are available. The simplest way is returning a set of available operations. If we want to be even more dense, then we return a query, which can be used on the documentation and which results the set of available operations. E.g. "all for type1 and a,b,c, but not d for type2 and all operations that start with 'x' for type3". If the resource representation contains the parameters for the IRI template, then it can be auto-filled, so many times all we need is just the operation names and no parameter description. Though this might make the response harder to process.

-- 
GitHub Notification of comment by inf3rno
Please view or discuss this issue at https://github.com/HydraCG/Specifications/pull/246#issuecomment-1372896454 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 5 January 2023 22:56:19 UTC