new API option: Can I create/edit/delete this resource please?

[MortenHofft]

The registry is constantly being expanded with roles and scoped editor access.
The UI is currently trying to follow along and duplicate this logic in the browser.
It would be really useful to have a way to query what actions were allowed for a given resource+user. It is less error prone, and the UI would always be in sync with the API.

Can I edit this resource please?

It could be an OPTIONS request or it could be a separate endpoint.

[MattBlissett]

"The response payload, if any, might also describe the communication options in a machine or human-readable representation"
https://tools.ietf.org/html/rfc7231#section-4.3.7

So it would be OK to have a response to an "OPTIONS /v1/dataset" request which said e.g. "Allow: HEAD GET POST" (as a header) and had a JSON body detailing which publishing organization keys the dataset would need to be in.

[MortenHofft]

I imagine that the UI will wrap all create/edit/delete buttons in a condition like

if canUser('POST', 'dataset') then show create button
if canUser('PUT', 'installation/123') then show edit button
if canUser('DELETE', 'organisation/123/machineTag/123') then show delete button
etc.

So using the OPTIONS request to decide what UI components to show. This doesn't solve everything of course, but it would go a long way.

It would not tell the client what constraints applies when creating/editing. E.g. that the user in case is only allowed to create datasets with a specific publisherKey. Or isn't allowed to create identifiers using the IH_IRN type. Those parts would still have be to handled in the client (duplicating the logic from the server), or possibly just failing at save with a useful error message from the server.

Making it even better
Or we could use the option to include additional JSON in the response to specify the allowed values per field (which I think is what @MattBlissett is suggesting as an improvement). E.g. something like

OPTIONS /v1/dataset/123
=>
PUT, DELETE, GET
body
{
  // simply showing a text message is fine and simple in the UI I think. It is less fragile
  messages: [
    {
      type: 'DATASET_PUBLISHER_CONTRAINT', // can be used for translations
      messages: 'You are only allowed to add datasets associated with publishers you have access to' // can be used as a fallback
    }
  ],
  // more complicated, but nicer for the user, would be to change the UI to only show legal values
  fields: {
    publishingOrgKey: {
      mustBe: ['1234']
    }
  }
}

I would be happy if we

• only show create/edit/delete buttons when allowed (e.g. based on OPTIONS request)
• simply show the user messages like: You can only change the dataset publisher to a publisher you have access to, without adding constraints in the UI on editing. That would mean little logic in the UI. Those messages would ideally come from the server before editing and if attempting to save something that isn't allowed.

[marcos-lg]

Finally using the checkPermissionsOnly param.

Deployed to prod.