1

I have a somewhat-RESTful API with a resource where I unconditionally PUT data to ensure it exists and is up-to-date. E.g.:

PUT /users/username/ HTTP/1.0
Content-Type: text/json

{"email": "username@example.org"}

Performing such requests, I don't care if user existed or not, I want the "create-or-update" logic. If user doesn't exist, it will be created (and I'll respond with 201 Created). If it already exists, API service will ensure its notion of user (email address) is up-to-date.

However, I wonder if it's semantically correct (with respect to the standards) to respond with 304 Not Modified (rather than the usual 200 OK) to non-conditional requests (without any If-* headers), in case the resource was already in that exact state and no change were performed.

So, my question is whenever standards allow such behavior, permit but discourage it, or prohibit it?

(Note: Adding ETags or modification times would be only a nuisance at the moment, and raise server- and client-side complexity. I don't want client-side to keep any extra state information at the moment.)

drdaeman
  • 11,159
  • 7
  • 59
  • 104

1 Answers1

0

No, it would not be correct (see https://greenbytes.de/tech/webdav/rfc7232.html#status.304).

Julian Reschke
  • 40,156
  • 8
  • 95
  • 98
  • Thanks! But is it definite? I know this RFC introduces this code for conditional requests, but not sure whenever other use is acceptable. I mean, I haven't found any mentions about non-conditional requests (i.e. no explicit prohibition "MUST NOT" or discouragement "SHOULD NOT" on use of 304 for requests that aren't subject of RFC7232), and standards are vast so I've decided to ask here. – drdaeman Jul 06 '16 at 10:50