basbl / ex_castor_edc Goto Github PK

There's likely to be more additions in the future that end-users might want to set (timeouts, for example). It could be nice to make that possible through an interface like:

def new(client_id, client_secret, opts \\ [])

Where opts is a keyword list that accepts :endpoint, :user_agent, :connect_timeout, :read_timeout etc.

This would be a breaking change though (unless you add a new/5 like def new(client_id, client_secret, endpoint, opts \\ []) but that starts getting unwieldy, especially as the same opts parameter needs to be made available on access_token()), so I didn't want to go there yet without some discussion.

On that note, another perhaps elegant way to model this is:

def new(credentials, opts \\ [])

# or:

def new(credentials, endpoint, opts \\ [])

Where credentials can be given as %{"client_id" => "...", "client_secret" => "..."} or %{"access_token" => "..."}. Then you could do away with the separate access_token/1 and access_token/2 functions.

Originally posted by @zoni in #18 (comment)

At the moment, the success/error API for this library uses a pattern of {<http_response_code>, <data>, <maybe more data>}.
For example:

{200, list_of_studies, _} = CastorEDC.Common.Studies.list(client)

This requires people to know what status code is expected from the api (are there cases where we get 201 instead of 200?) and it makes it a little less ergonomic to incorporate into with statements or approaches advocated by the OK library.

Furthermore, calls may generate an exception, for example on networking errors, due to the use of exception-raising Tesla methods. For example:

I have not explored how much effort it would be to actually adjust this, but I believe we may be able to make error-handling patterns more friendly to end-users if the following conventions were adopted:

1. Regular API calls will only ever return {:ok, data} or {:error, reason} tuples.
2. (Optional) ! methods are provided to do automatic unpacking/raise-on-error behavior. (list_of_studies = CastorEDC.Common.Studies.list!(client) in the example above)

What are your thoughts on such a design?