Skip to content
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

PATCH to create #231

Closed
michielbdejong opened this issue Feb 9, 2021 · 5 comments
Closed

PATCH to create #231

michielbdejong opened this issue Feb 9, 2021 · 5 comments

Comments

@michielbdejong
Copy link
Contributor

NSS and PSS support PATCH to create. This means that if do an inserts-only PATCH to a URL that is a 404, that resource is created on the fly. CSS does not support this.

https://github.com/solid/solid-crud-tests/blob/master/test/surface/create-non-container.test.ts#L167 is the test in the test suite for it.

I found the text "a server creates a resource on HTTP [...] PATCH requests" but I didn't find an explicit statement saying "servers must support PATCH to create".

The old spec said "If the resource doesn't exist, it should be created through an LDP POST or through a PUT." but that's a very old text, predating current NSS behaviour.

I think Solid OS depends on this behaviour, for instance when adding a chat message, if that message happens to be the first message on that day, the document for it gets created on the fly. It's handy. :)

@bourgeoa
Copy link
Member

bourgeoa commented Feb 9, 2021

Doesn't this MUST imply PATCH create :
Servers MUST create intermediate containers and include corresponding containment triples in container representations derived from the URI path component of PUT and PATCH requests

@csarven
Copy link
Member

csarven commented Feb 9, 2021

A part of the issue #68 included some discussion on PATCH to create a resource. A conclusion was reached in this issue to allow recursive container creation for PATCH. The requirement for this is made it into the spec (after review and approval):

Servers MUST create intermediate containers and include corresponding containment triples in container representations derived from the URI path component of PUT and PATCH requests.

Noting here that this requirement is only meaningful for non-existing resources. Also noting that this does not dependent on media type. In practice, I would take that as to apply only to payloads with the intent to 'add' information (at the very least) eg. with application/sparql-update, INSERT DATA would result in the creation of a resource, and DELETE DATA wouldn't.

Another requirement in the spec that also supports PATCH to create based on the review in #160 (comment) and approval of:

Clients who want to assign a URI to a resource, MUST use PUT and PATCH requests.

Aside: the table on PATCH in this comment: #14 (comment) has a row for "Write, INSERT DATA, , 200, 201" ie. creating C/R if it doesn't exist.


Having said that, there may be other discussions in support of PATCH to create, but equally possible that we've overlooked some conflicting agreements. Also possible that there is a mismatch between what was agreed with what's in the spec. So, I'm all ears.

I'm also interested in knowing why CSS as well as any other server chooses not create a resource with PATCH. Worth bearing in mind that what's currently in the spec (or at least strongly implied) can change if there are good reasons to do so.

@acoburn
Copy link
Member

acoburn commented Feb 9, 2021

I believe the spec discussions have been really clear on this issue, namely that PATCH can be used to create resources.

I can independently confirm that CSS supports PATCH-to-create.

@michielbdejong
Copy link
Contributor Author

Great!
Thanks for clarifying.

@michielbdejong
Copy link
Contributor Author

Great! I independently confirmed that ESS also supports both PATCH-to-create and PUT-to-create, both including the mkdir-p behaviour.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants