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

Paul Bruton commented on COEL-42:
---------------------------------

Extracts from email to group:

I have been reviewing mine and David's changes to IDA, MMI and PQI for COEL-42 (error codes) and we have overlooked something in the IDA <-> Operator <-> Data engine workflow: 

From IDA: 
·        Data Engines receiving a failed validation code [from the IDA] MUST pass the failure back to the Operator. 

·        Operators receiving a failed validation code from the Data Engine MUST discard the Pseudonymous Key and request a new one from the IDA.

·        If the second attempt also fails, the Operator SHOULD try once more after a short delay (1-2 seconds) before aborting the attempt to register. 



The problem we have is that the IDA uses the response body to indicate sucessful or failed validation, always returning a 200 code and a body of {"Result": "true"} or {"Result": "false"}.  However we have removed the response body Data Engine API (operator/consumer and operator/device) so the Data Engine has no means to tell the Operator that their response was valid, but the PseudonymousKey that was passed in cannot be used. 

I think our best way to fix this is NOT to use the response body to indicate an unsucessful validation, but instead use an explicit HTTP Status code of '410: GONE':

Thus, the IDA Validation method would return one of the following [changes from SPEC highlighted in *bold*] 

*200: The operation was successful. The Pseudonymous Key is valid. * 

400: The operation failed due to the request body being malformed.  

401/403: The operation failed due to authentication or authorization failure. The caller should confirm its credentials and retry.

*410: The operation was successful (i.e. well formed response body) but the response key is no longer valid.* 

500: Internal error, the caller should retry 


The Data Engine operator/consumer method will use the same pattern and return: 

*200: The operation was successful. The Pseudonymous Key is valid and the Consumer has been registered * 

400: The operation failed due to the request body being malformed. *(Could also be because some segment parameter is invalid: Reason field in the response will help)* 

*410: The operation was successful (i.e. well formed response body) but the response key is no longer valid and the Consumer has NOT been registered *

500: Internal error, the caller should retry 


We would implement the same pattern for registering devices and operators.

I will upload some changed documents today (a few minor spelling changes) but we should discuss this on Tuesday next to agree a way forward. Obviously this impacts on implementations but the newer approach is cleaner in my opinion. The 410 code is quite appropriate because if we view the PseudonymousKey as a resource that the IDA has created, then a request for its validation would return 404 if we failed to find it (but please try again) whereas a 410 says it is permanently gone (out of date, deleted etc). 



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