Why limit the the response status codes that would trigger a notification?

[joachimvh]

The spec defines that PUT/PATCH/DELETE requests should only trigger a notification when the server responds with a 200/204. Why the specific limitation to those status codes instead of just saying a successful request? When a PUT/PATCH creates a resource the status code would be 201 for example. And the CSS returns a 205 when those update an existing resource.

Related: solid/specification#288

[CxRes]

I am happy to add 205 to the list (so split PUT/PATCH from DELETE; 205 is meaningless for DELETE imho). Do you think adding 205 is necessary for POST as well?

As For:

Why the specific limitation to those status codes instead of just saying a successful request?

1. This is to explicitly exclude:

   • 202 Accepted
   • 203 Non-Authoritative Information

   from triggering notification.

2. I also think it is a good idea to exclude:

   • 206 Partial Content

   for Partial PUTs, because these are not specified for Solid (and it is required that such arrangements are specified).

3. And

   • 201 Created

   is meaningless for PREP because you cannot GET notifications if the resource is 404 (something I could consider adding support for in PREP, but it brings with it another set of complications).

[joachimvh]

A 205 would be sufficient for CSS, but as status codes are not fixed in the Solid spec there is no guarantee this covers everything.

For example, a server might return a 202 on a DELETE request for any kind of reason. If it then decides to actually execute the request and perform the removal, it should still send out a notification right?

Regarding the 201, if someone listens to a container /foo/, and a resource is created by doing a PUT to /foo/bar, should there not be a notification that a resource was added to /foo/?

The Solid specification only talks about things like a "successful PUT request", so it might make sense to use the same descriptions here. See https://solidproject.org/TR/protocol#resource-type-heuristics

[CxRes]

For example, a server might return a 202 on a DELETE request for any kind of reason. If it then decides to actually execute the request and perform the removal, it should still send out a notification right?

The server will NOT send a notification upon a 202 Accepted response (because the resource is still unchanged). Where you are correct is that if the resource changes, whether it is, as in your example, that a request is run at a later time or the resource is modified through another protocol, a notification SHOULD be sent. And I should explicitly add this to the specification.

Regarding the 201, if someone listens to a container /foo/, and a resource is created by doing a PUT to /foo/bar, should there not be a notification that a resource was added to /foo/?

Good Catch! But, I need to add another category where notification is sent only on the container for 201 responses.

The Solid specification only talks about things like a "successful PUT request",

This is rather specific to resource creation. There are almost no other references (of consequence, anyway) of successful responses or 2xx status codes in the Solid specification.

In trying to strike a balance between under-specifying and risk implementations doing their own stuff v/s over-specifying and missing out on legitimate use cases, I have chosen the notifications to be a SHOULD. There is no MUST NOT stopping notifications for other cases, it is just that they are not recommended here. If we add those in the future, it should not affect backwards compatibility with current Solid-PREP spec. On the other hand, if I allow cases that need to be removed, that will be a breaking change.

But, I hear your concern that any client would want to know about all resource state changes (and not miss out on any).

[CxRes]

@joachimvh Please review #3.

[CxRes]

Fixed with #4.