8000 Added "allow" attribute for links to restrict access by aimeos · Pull Request #1126 · json-api/json-api · GitHub
[go: up one dir, main page]

Skip to content

Added "allow" attribute for links to restrict access #1126

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: gh-pages
Choose a base branch
from
Open

Added "allow" attribute for links to restrict access #1126

wants to merge 1 commit into from

Conversation

aimeos
Copy link
@aimeos aimeos commented Dec 11, 2016

This PR relates to the discussion in #745

If access to a 8000 resource is limited by a permission system, the HTTP header that can be sent along with the resource is "Allow: GET, PATCH, DELETE". For included resources, the link attribute should be able to list the allowed methods the same way:

"links": {
  "related": {
    "href": "http://example.com/articles/1/comments",
    "allow": ["GET", "PATCH", "DELETE"]
  }
}

to be as close as possible to the HTTP header. Only "Allow" should lower-case to be in line with all other keys in the JSON payload.

This PR relates to the discussion in #745
If access to a resource is limited by a permission system, the HTTP header that can be sent along with the resource is "Allow: GET, PATCH, DELETE". For included resources, the link attribute should be able to list the allowed methods the same way:
```
"links": {
  "related": {
    "href": "http://example.com/articles/1/comments",
    "allow": ["GET", "PATCH", "DELETE"]
  }
}
```
to be as close as possible to the HTTP header. Only "Allow" should lower-case to be in line with all other keys in the JSON payload.
@jelhan
Copy link
Contributor
jelhan commented Feb 4, 2022

Thanks a lot for your proposal.

Looking at v1.1 this could be addressed using an extension as well. Doing so would be better in my perspective:

  1. Extensions allow us to experiment outside of the main spec. An extension dies not have the same backward compatibility guarantee as the main spec. This allows it to move much faster.
  2. Discovering available methods for an API endpoint programmatically is a requirement only some APIs have. I think it would be better to not force the complexity of adding a feature to all others as well.

@jelhan jelhan added the extension Related to existing and proposed extensions as well as extensions in general label Feb 4, 2022
@bednic
Copy link
Contributor
bednic commented Feb 28, 2023

HTTP methods discovery should be done by HEAD or OPTIONS methods

@aimeos
Copy link
Author
aimeos commented Mar 1, 2023

@bednic That's not practical for all the links in the sent JSON response because they can have different allowed methods, e.g. GET for all resources, POST/DELETE only for adding/removing products into/from the basket. Doing OPTIONS requests for each link would generate a lot of request which should be avoided.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
extension Related to existing and proposed extensions as well as extensions in general
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0