1

I have a resource which cannot be updated (events). Hence I am allowing only Post & Get operations. (I haven't chosen PUT because the eventId is generated at server end and returned as part of response).

I already have a combination of three fields in the input which can be used to identify a unique resource.

Given this, if someone posts same request twice, this is what I am expecting to return

  • case 1: If unique fields already exists in DB and complete request is exactly same as previous one, then we just ignore this request (since the resource already exists).
  • case 2: if unique fields already exists in DB BUT other part of request is different, then send error response saying it's not supported.

What should be the correct response code to return in both case 1 & case 2.

Thanks, Harish

Harish
  • 7,589
  • 10
  • 36
  • 47

2 Answers2

2

If the call is idempotent, meaning case 1, I would expect it to return a 200 OK because it did not really fail, it's the same as updating with the same values when doing a PUT.

If the call is not idempotent, meaning case 2, then I would expect a 409 Conflict even if the user should not actually retry the call. That's because by what you said, a user is actually allowed to send a request with the same identifiers, provided that all of the other parameters are also the same.

Also, but this is just my gut feeling, if a user tried different parameters to see the different kind of response code, he could determine the current status of a resource even if maybe he was not allowed to read it. So, depending on the scope of your application, you may want to give the same response back.

ChatterOne
  • 3,381
  • 1
  • 18
  • 24
  • I like your though of possible security leak if that user was not allowed to read. Though that isn't my current use-case. For case 2, how about using 422 ? – Harish Apr 13 '16 at 15:26
  • Response 422 is specifically indicated for cases like a semantic error, which in your case is nor really true, because if the second request came first, it would have also been semantically correct. The second request is not specifying out-of-range parameters or something similar, so I would say it's not a 422. – ChatterOne Apr 13 '16 at 15:41
  • Thanks. Certainly makes sense that if second request came first.. then it can't become magically syntactically correct. Thanks for the clarifications. Will go with 200 for case 1 & 409 for case 2. – Harish Apr 15 '16 at 09:12
1

EDIT:

Since neither 409 or 400 fit your case, perhaps 422 Unprocessable Entity

http://www.restpatterns.org/HTTP_Status_Codes/422_-_Unprocessable_Entity

Perhaps 409 Conflict is what you're looking for.

https://httpstatuses.com/409

If you want to signal to the client that the failure is 'final' and no request editing will change that, another option is 400 Bad Request.

Personally I only use 400 when request syntax is illegal - which is not the case here.

morsor
  • 1,263
  • 14
  • 29
  • I saw that.. But 409 says, user can resubmit the request after making corrections. But in my case it's just not supported and user shouldn't retry as the resource already exists and we don't support updates. Hence I cant use 409 – Harish Apr 13 '16 at 10:54
  • Then perhaps 400 - bearing in mind that many/most would deem using it inappropriate. – morsor Apr 13 '16 at 11:00
  • 1
    Or 422 Unprocessable Entity – morsor Apr 13 '16 at 11:04
  • 422 seems to be fine for case 2 (though I am still not sure if case 2 falls under semantic errors category). Also what should be the error code for case 1? – Harish Apr 13 '16 at 11:41
  • I would personally use the 409, as it indicates that the user MIGHT be able to resolve the conflict and advises that the server returns an explanatory payload. – morsor Apr 13 '16 at 11:46
  • But for case 1, there is no need to retry from client. The entity already exists so all is good. Is there any response code which mentions "Resource Already Exists?" – Harish Apr 13 '16 at 13:26
  • This might violate your goal - but if the client wishes to create something which already exists, you could return 200 OK. Depending on whether you INSIST the client is notified of the mistake – morsor Apr 13 '16 at 13:31
  • ok. I get your point. 200 seems fine for case 1 as I am not too much worried about informing the client that he did a mistake. For case 2, I am still trying to understand what "semantic error" means and if that matches my use case.. then will go with 422 – Harish Apr 13 '16 at 15:25