Re: [Specifications] Retracting operations (#241)

> The reason operations are retracted or overridden – whether it's due to business logic or the lack of permissions – doesn't really matter, imho

That's my point of view as well as I do not wan't to model permissions.

> Well, I tend to document all available operations in ApiDocumentation ... I then only enable each operation in a UX if it is in the operation property inline in the response for that resource

This is against the specification. All operations declared in API Documentation and inlined are complementary - there is no mechanism of overriding neither the hiding of previously declared operations.

>My thinking would be availability: Available | NotImplemented | Forbidden | Unauthorized | ConflictsWithCurrentStateOfResource | myapi:DisabledByAdministrator, maybe making this a class that includes the enabled, and a description that could be useful in rendering user experience?

I like the idea of providing an `availability`. While it should not matter from the client point of view (server can always say i.e. `Forbidden`), it might be useful to display some kind of explanation for humans why the button is greyed out.

Example:

```http
GET /api?documentation

{
  "supportedClass": "api:User",
  "api:User": {
    "supportedOperation": {
      "@id": "api:deleteUser",
      "method": "DELETE"
    }
  }
}
```

```http
GET /api/user/1

[{
  "@id": "api:deleteUser",
  "availability": "hydra:Forbidden"
}]

-- 
GitHub Notification of comment by alien-mcl
Please view or discuss this issue at https://github.com/HydraCG/Specifications/issues/241#issuecomment-878029165 using your GitHub account


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

Received on Monday, 12 July 2021 07:09:00 UTC