switch from 404 to 200 response from REST API when there's no error

[KipK]

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 {} ?

[jeremypoulter]

Yes an empty object should be returned (apart from the DELETE) where we are also returning {"msg":...} in other 200 cases

[jeremypoulter]

We may also have to consider replacing the DELETE method with something else... I think that is the main reason I went for 404

[jeremypoulter]

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

[KipK]

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.

[KipK]

We may also have to consider replacing the DELETE method with something else... I think that is the main reason I went for 404

not sure of what to do on this. DELETE still looks appropriated to remove ressources. What would fits better according to you?

[jeremypoulter]

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.

[KipK]

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.

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 ?

[jeremypoulter]

Maybe we can do the PUT changes as a separate PR (or rather expanding the scope of where PUT is used)

[KipK]

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.

[jeremypoulter]

Looks good to me, does this need a GUI change as well?

[KipK]

No main tree is ok. 👍