[OASIS Issue Tracker] (COEL-42) Better error reporting across the suite

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/COEL-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61496#comment-61496 ] 

David Snelling commented on COEL-42:
------------------------------------

Folks,

Here are my thoughts. The spec or the current DE emit the following codes: 200, 202, 400,401, 403, 404, 405, 415, and 500. I think these are about right. Usage guidelines as follows:

200: OK - The application worked. Note that for true/false questions, like the IDA's validate ID, the client will need to look for a {"Result", true/false}.
202: Accepted - I propose that this be the response to ALL unauthenticated posting of Atoms. The DE spec will offer optional support for better QoS to authenticated connections to facilitate debugging following the guidelines below.

400: Bad Request - Something is wrong with the request and the specs should say something like, " ... MAY return a JSON object containing a "Reason" field encoded as a striing, e.g. {"Reason", "Operator not registered."}
401: Invalid Un/Pw - Pretty self explanitory and not really returned by implementers of the spec.
403: Unauthorized - Unlike 401, this will come from inside the implementation. More details MAY be provided following the same patern as with 400.
404: Not Found - Pretty self explanitory and not really returned by implementers of the spec.
405: Method Not Allowed - This is a good one to define for all specs and again helpful detail MAY be provided as with 400.

415: Unsuppported Media Type - This is a refinement of 400 and we could probably drop it. It is currently specified in the BAP to be returned by the DE when a GET on /home includes a body. Otherwise, it isn't in the specs or implementation. Might be useful to respond quickly to requests that say they are not 'application/json', but I would be happy just returning 400.

500: Internal Error - Clearly a nasty problem for the implementer and MAY include a reason like 400.

[Ref: https://en.wikipedia.org/wiki/List_of_HTTP_status_codes].

I think we shuold drop the {"Result", true} response body for operations that either work (200) or fail (4xx, 5xx), e.g. Operator Registration. The 200 response should be empty and the 4xx or 5xx response should (optionally) be a {"Reason", "..."} object.


> Better error reporting across the suite
> ---------------------------------------
>
>                 Key: COEL-42
>                 URL: https://issues.oasis-open.org/browse/COEL-42
>             Project: OASIS Classification of Everyday Living (COEL) TC
>          Issue Type: Improvement
>         Environment: MMI, PQI, and maybe others.
>            Reporter: David Snelling
>            Assignee: David Snelling
>            Priority: Critical
>
> Alan wrote: 
> Further to my last question, I see that if I attempt to register a consumer with some dodgy data I do indeed get a 200 response with { “Reason”: “Consumer ID is not valid”, “Result”: false } so I will make sure I decode this.
> I appreciate this is all in the spec now (and it’s a minor detail), but would it not be neater to return a 4xx code for failure here (and other requests)? The BAP seems to be pretty detailed on the use of different response codes, the others less so.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)