On Nov 5, 10:55 am, jaredm <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> I'm nearing completion of our integration work using the .NET API. I
> want to double-check that I'm handling all potential errors correctly
> and that I understand what they mean. The below assumes that I
> already have (what I believe to be) a valid long-life token for a user
> and I'm trying to submit a notice with a CCR payload to his/her Google
> Health profile.
>
> The "go-live" checklist says there are 3 errors to handle, in my
> testing and from reading the authsub reference docs these are the
> errors I've seen:
>
> HTTP 400 Bad Request - This usually means the CCR portion of the
> notice is malformed which is often caused by bad or missing data in
> our EHR.
>
> HTTP 401 Unauthorized - A token is no longer valid, has been
> invalidated by the user or has otherwise expired.
401s are usually for revoked/invalid tokens:
http://code.google.com/apis/gdata/auth.html#AuthSub
>
> HTTP 403 Forbidden - Essentially the same as a 401 error, meaning the
> token is no longer valid and must be exchanged for a new one. I'm not
> entirely sure what the differences between a 403 and 401 are and if
> that matters as far as how I handle the two errors.
403 is more or less the samen,...meaning you don't have access to the
resource
(for whatever reason). For example, if your AuthSub token wasn't
requested
with the permission=1 parameter, trying to read a user's profile will
yield a 403:
http://code.google.com/apis/health/getting_started.html#Troubleshooting
>
> I'm assuming that a 401 or a 403 means the token is broken and must be
> refreshed. If I catch one of those errors I will remove the token
> from our database and notify the user that the link is down and give
> them the option to retrieve a new token. Is this best practice?
I would read the body of the server's response (or the library's
exception)
and proceed accordingly.
>
> For a 400 error I'm assuming that the data is bad on my end, I will
> record a reference to the faulty data and ignore that specific record
> until the problem can be resolved. Are there any other common causes
> of a 400 error that I should be concerned with?
Status codes are listed in the general Google Data docs:
http://code.google.com/apis/gdata/reference.html#http-status-codes
>
> Thanks for your time,
> Jared
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Health Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/googlehealthdevelopers?hl=en
-~----------~----~----~----~------~----~------~--~---
