HTTPStatus-Codes in error-cases

[AndreasSchultzGEA]

Hi,
my name is Andreas and I'm back ;-) and working together with Beate and Thomas at GEA.

If a request - e.q. for all locations - fail, a http-code != 200 should indicate what has failed.
For example, Authorisation-fails could be answered by 401, etc.
Exists plans to optimize this?

[cookeac]

Agreed. The standard set of HTTP codes should be available; and an error response returned.
There is some discussion of this with reference to POST semantics in #154 but the same approach should apply to GET.

[ahokkonen]

Personally I would like to avoid complexity of passing different fail statuses for different cases. :)

I would say 401 and 403 are mandatory for describing failure for authentication/authorization, but for all the rest BL failures, in my opinion, 400 (Bad Request) response with additional text description for the error (error resource) is enough.

[ghost]

From my past experience: if you want to have automated communication between multiple parties, the standard error cases have to be clear. For the ReST layer, I think error codes are a good way of handling the default error case. Otherwise we would have to agree on error codes between all the parties because if that is not done, all parties have to implement new error handling for each partner they communicate with.

Well, if the standard HTTP error codes are not sufficient to cover the default error cases, we should at least come up with a standard error scheme for our ICAR interface that becomes the default while leaving the option for parties to add additional codes. Just my 2 cents...

[cookeac]

Will be addressed by the semantics for POST event (#154) and the updates to the example URL schemes.