Implement transparent client pattern and middleware error handling #147
Conversation
| action_attempt_id: action_attempt.action_attempt_id | ||
| } | ||
| ) | ||
| response = client.post("/action_attempts/get", {action_attempt_id: action_attempt.action_attempt_id}) |
There was a problem hiding this comment.
| response = client.post("/action_attempts/get", {action_attempt_id: action_attempt.action_attempt_id}) | |
| response = client.get("/action_attempts/get", {action_attempt_id: action_attempt.action_attempt_id}) |
| @client = client || Seam::Http::Request.create_faraday_client(@endpoint, @auth_headers, faraday_options, | ||
| faraday_retry_options) | ||
|
|
||
| initialize_routes(client: @client, defaults: @defaults) |
There was a problem hiding this comment.
What does this do? Why is it defined as a private function but called here?
There was a problem hiding this comment.
initialize_routes is an internal method to set up route clients by making available @client and @defaults for them. SingleWorkspace can access private initialize_routes because Routes module gets included in the class. While the method will exist on instances, being private it can only be called internally (inside the class/module methods) and not from outside code, unlike public methods like 'devices', 'access_codes' etc. which can be called by anyone using the instance.
| body = begin | ||
| JSON.parse(env.body) | ||
| rescue | ||
| {} | ||
| end |
There was a problem hiding this comment.
We can't assume the response is always JSON. It's possible for things in front of the API to return errors that are not JSON like Bad Gateway or Service Unavailable. I checked and the python SDK has the same assumption: https://github.com/seamapi/python/blob/7b62fa7eab7094d36af6f74465d4703da94d4330/seam/client.py#L64
We may need to replicate this logic in all the SDKs: https://github.com/seamapi/javascript-http/blob/8178e4f42e89198defdcda0a83a7b6ed4b482066/src/lib/seam/connect/error-interceptor.ts#L34-L61
I'm not sure we should keep the default "unknown" values either: the error needs to have a type and a message to be considered a Seam error.
Basically:
- Check for 401 status code and throw our custom SeamHttpUnauthorizedError
- Try to determine if the error response can reasonably assumed to be a JSON error from the Seam API and throw it as either a
SeamHttpInvalidInputErroror the genericSeamHttpApiError. We can still default - Otherwise, we just throw the error provided by the underlying http client.
Closes #137