Skip to content
Captain-P-Goldfish edited this page Feb 23, 2020 · 3 revisions

No exception on none matching patch-filters?

RFC7644 says that a bad request should be returned if the client forms a filter within a patch-path that retrieves no results. I intentionally violated the specification on this behaviour. I discussed this issue with several developers and got unanimous assent. Taking a look onto this issue from an SQL view not an error message would be returned but a success response that tells us "0 rows are affected". The patch implementation within this framework behaves similiar. It simply returns an http status 200 (OK) and the patched resource (which was not patched in this case).

Why did I do this?

If the developer forms a filter that should create a resource state that is already matched I do not see a reason to punish this with an exception. This would be utterly confusing. For example imagine the filter patch remove operation emails[type eq "work"]. If there is no email that specifies a type for work within the resource the desired state is already the current state. So I thought that returning an error message would just lead to confusion which is why I decided to to return a http status of 200 instead with an unchanged resource