-
Notifications
You must be signed in to change notification settings - Fork 299
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
POST/PUT in NSS allow multiple resource with same url and different content-type #1529
Comments
No issues with either one of those. They will create/replace resource given representation depending on request semantics. If /foo.txt exists, /foo.txt/ should not, and vice-versa. Redirect is optional. |
@csarven thanks |
Hmm, not exactly sure what you are after.. but there is no limit on how many or what representations can potentially be made available for a resource. Just one per request. If you are considering whether to store one or more representations and have one of them available at request, that's entirely your (NSS's) call. You'll have to take care when updating of course. |
Is this correct?
|
I don't think it is a bug as long as the correct representation is returned given the respective Accept header on GET |
@angelo-v If it where different representations of the data, do you know how to replace the data ? I was with the idea that a representation should be stored in the format of the
nota : my comments are not using the specification language, i'm just on the practical side |
is this a 409 or a 403 ? I was thinking of 409 conflict - forbidden by the context not as such. |
POST is an append operation, so server should append to the existing resource. POST to a (non-container) resource with an existing representation is currently unspecified in the specification. This is intentional. Whether that's possible for any media-type or how that's done is unspecified. However, we have discussed RDF merge as a good candidate, and that's likely to come into the specification. I'll have to review the issues before adding it in. RDF merge will happen when request Content-Type uses the media-type of an RDF document eg. text/turtle, application/ld+json, application/trig, text/html, application/xhtml+xml, image/svg+xml etc. The server is not required to support any or all of that. If it does merge, the encoded RDF graph should be the result of the merge of RDF triples.
Fail (most likely) or redirect to /foo.txt. This is mentioned in the specification without ties to HTTP methods:
I'll try to further clarify requests like "/foo.txt exists [..] POST /foo.txt/". I suggest responding with the 404 status code. You could later consider including a response body with the problem details ( see solid/specification#28 ) and/or use the ldp:constrainedBy for the link relation type ( see solid/specification#185 ).
No. It should respond with 200 or 204 (while adhering to other requirements eg. not changing the containment triples), or possibly 202.
No. 404. The request target is /foo.txt and it doesn't exist. Nothing to append to. It doesn't matter if /foo.txt/ exists. When authorization is taken into account, 403 should precede 404 where applicable. See solid/specification#14 (comment) for more details. I plan to integrate the information from that comment into the specification, if not already covered.
Only if the request included the Link header with LDPC, create /foo.txt/{id}/ , otherwise create (non-container) resource /foo.txt/{id} as per:
|
Servers are not required to "store" different representations or have URLs for them different than the resource URL. Server just needs to respond with a representation when a resource is requested. Server can choose to expose representation URLs for read operations, however, for write operations, client needs to go through the resource URL. See https://solid.github.io/specification/#resource-representations |
You can create resources :
text/plain
=> creates file :/foo.txt
text/turtle
=> creates file/foo.txt$.ttl
/foo.txt
The first 2 have the same url and there are 2 different files created.
All 3 have the same visual representation in SolidOs.
The first 2 should not occur and I think this is a bug
For the third one I remember @timbl writing it should not occur, but did not find where.
There was also a redirect discussion between foo/bar/ and foo/bar. His this something to do in GET ?
Is there any solid/specification, I did not find anything ? @csarven @michielbdejong
The text was updated successfully, but these errors were encountered: