Re: [Specifications] Retracting operations (#246)

> Anyway, I shall then replace `hydra:Forbidden` with something else as it was not my goal to mimic HTTP status codes. By naming it _forbidden_ i had in mind exact meaning of this word - the operation is forbidden, even if it was announced earlier, it is available - client mustn't call it at any circumstances.

If a `hydra:Forbidden` operation is executed by the client due to having stale metadata or whatever other reason, isn't it natural to think that the server would respond with a `403 Forbidden`?

> I've added `hydra:Unauthorized` as state related to user capabilities might be of interest - it is somehow available, but at the different circumstances.

Exactly. So if a client inadvertently executes an operation currently marked as `hydra:Unauthorized`, the server would respond with `401 Unauthorized`. Right?

> All these terms introduced are related to _retracting_ operations - HTTP status codes 5XX has nothing to do with retracting - these are server errors and I don't think it is a normal approach to expect those in any circumstances.

I tried to outline a use-case where this may be. Hopefully the below diagram makes it clearer:

```mermaid
sequenceDiagram
    participant Client
    participant Server
    participant U1
    participant U2

    Client->>Server: GET operations
    activate Server
        Server->>U1: GET operations
        activate U1
            U1->>Server: 503 Service Unavailable
        deactivate U1
        Server->>U2: GET operations
        activate U2
            U2->>Server: 200 OK { operations }
        deactivate U2
        Server->>Server: Aggregate operations
        Server->>Client: 200 OK { operations }
    deactivate Server
````

Client asks Server for its available operations. Some of Server's operations are delivered by upstream servers U1 and U2. To deliver a fresh list of available operations to the Client, Server asks U1 and U2 for their operations. U1 is currently unavailable and responds with HTTP `503 Service Unavailable`. U2, however, is available and responds with its operations.

Server then aggregates the operations from U1 and U2 and responds to Client with U1's operations marked as `hydra:Unavailable`.

> Maybe a situation, when an operation is still _available_, but not with current application state - i.e. `hydra:Unavailable` might be useful, but I feel this would be a long shot.

Perhaps. I think it's good to hash this out thoroughly, nonetheless. :)

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


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

Received on Tuesday, 11 October 2022 19:16:49 UTC