Closed KipK closed 1 year ago
Yes an empty object should be returned (apart from the DELETE
) where we are also returning {"msg":...}
in other 200
cases
We may also have to consider replacing the DELETE
method with something else... I think that is the main reason I went for 404
Actually some of those should be 404
, eg if you fetch /schedule/1234
and that does not exist 404
is valid to return. However when you are posting to a fixed resource like /limits
an empty object is more appropriate.
Also on the subject of HTTP error codes I noticed a few cases where JSON parsing is returning 500
these should be a 4xx
return code asit is a client error not a server error, probably 400
Also on the subject of HTTP error codes I noticed a few cases where JSON parsing is returning 500 these should be a 4xx return code asit is a client error not a server error, probably 400
HTTP 415 should also fit well for this : The HTTP 415 Unsupported Media Type client error response code indicates that the server refuses to accept the request because the payload format is in an unsupported format.
We may also have to consider replacing the
DELETE
method with something else... I think that is the main reason I went for404
not sure of what to do on this. DELETE still looks appropriated to remove ressources. What would fits better according to you?
So I think for specifiic instances of things (eg /schedule/1234
) we stick to DELETE
with 404
return code. If the client is fetching these when they don't exist I see that as a bug or assumption on the client side. the client should use the /schedule
endpoint to get the list of valid resources.
For other cases where it is a fixed resource we should POST
(or maybe PUT
) something to clear the resource, probably and empty object so it then makes sense to get back an empty object when you fetch that endpoint again.
on the JSON parsing I think we go with 400
seems more appropriate and inlne with other uses in the API.
For other cases where it is a fixed resource we should
POST
(or maybePUT
) something to clear the resource, probably and empty object so it then makes sense to get back an empty object when you fetch that endpoint again.
Agree /limit PUT {}
, /override PUT {}
, sounds logical.
Shouldn't we also use PUT for creating them?
and what about /claim/{id} and /schedule/{id}, switch to PUT too ?
Maybe we can do the PUT changes as a separate PR (or rather expanding the scope of where PUT is used)
Maybe we can do the PUT changes as a separate PR (or rather expanding the scope of where PUT is used)
yes , considering it will also be a braking change for current implementations. Those ones currently shouldn't break anything.
No main tree is ok. 👍
Fix browser console spawning HTTP 404 error when API answer was correct. Was preventing to catch real 404 errors.
@jeremypoulter , do you think we should also change the {msg: "no override"} and co by empty objects {} ?