[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=61509#comment-61509 ] 

Paul Bruton edited comment on COEL-42 at 1/5/16 2:15 PM:
---------------------------------------------------------

I agree with David. I looked through the BAP, IDA, MMI and PQI and here are my recommendations:

IDA: No significant change required. It already returns 200 on a successful call. The caller must check the response body because it is either a pseudonymous key or the output of a validation. The IDA will return 400 in case of malformed input but we do not document that. It returns 401 or 403 appropriately for unauthenticated or forbidden calls.

BAP: I agree that we should return a silent 202, but I think it is a strong recommendation to have a 400 returned with some information if there are mandatory fields missing (e.g. no consumer ID, timestamp etc). We ought to be clear about what these minimum checks are.

MMI: The calls that create resources (e.g. operators or consumers) do not need to return a response body, just a response code: They should return 200 if successful and a 400 if the request was malformed. I would like to see the MMI return 200 if a second or subsequent identical call is made to create the same resource: this offers resilience to clients if the communication channel fails to return the first time, they can retry without any special logic. (idempotent)

PQI: NO significant change to response codes but we should strongly recommend checking query syntax.

Data engine does not need to return 403 as it does not implement separate roles like the IDA does


was (Author: paul.bruton):
I agree with David. I looked through the BAP, IDA, MMI and PQI and here are my recommendations:

IDA: No significant change required. It already returns 200 on a successful call. The caller must check the response body because it is either a pseudonymous key or the output of a validation. The IDA will return 400 in case of malformed input but we do not document that. It returns 401 or 403 appropriately for unauthenticated or forbidden calls.

BAP: I agree that we should return a silent 202, but I think it is a strong recommendation to have a 400 returned with some information if there are mandatory fields missing (e.g. no consumer ID, timestamp etc). We ought to be clear about what these minimum checks are.

MMI: The calls that create resources (e.g. operators or consumers) do not need to return a response body, just a response code: They should return 200 if successful and a 400 if the request was malformed. I would like to see the MMI return 200 if a second or subsequent identical call is made to create the same resource: this offers resilience to clients if the communication channel fails to return the first time, they can retry without any special logic. (idempotent)

PQI: NO significant change to response codes but we should strongly recommend checking query syntax.

> 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)