Figured this might be better off as a separate issue/proposal stemming from #25 .
The idea is to decouple the implementation of building API requests from Tesla with an ExForce.Request{} struct that can be composed into an ExForce.CompositeRequest or ExForce.BatchRequest. This could enable more explicit behavior specs as described in #26 and ideally allowing for easier switching out of the HTTP library.
Started an initial mock of what the structs could look like here:
As the Composite Resource responses also have sub-responses an ExForce.Response{} like described in #25 would allow for a ExForce.CompositeResponse with the list of ExForce.Response{} structs to be returned.
@spec composite_request(Client.t(), list(%ExForce.Request{}), boolean()) :: {:ok, %ExForce.CompositeResponse{}} | {:error, any}
def composite_request(client, requests, all_or_none) do
...
end
As described, this would be a large surface area change. Maybe an interim option is to just use the current approach (Tesla.Env{} responses) and add Composite Resources functions like shown here. The trade-off being a lot of the Salesforce API implementation bleeds into the consuming application by having to build a compatible data structure for the resource (e.g. %{"allOrNone" => "true", "compositeRequest" => composite_requests}) and parse out the response bodies.
Thanks for the idea - I haven't used sub-request / sub-response, but it looks useful.
Something to think about
whether to expose or hide composition (e.g. accept a list of requests vs a composite request struct)
how to provide both raw HTTP request/response and sub request/response nicely (e.g. good type support)
how to handle some technical difference - e.g. looks like Salesforce uses map with case sensitive key, not array with case insensitive key (which is correct per HTTP spec).
Figured this might be better off as a separate issue/proposal stemming from #25 .
The idea is to decouple the implementation of building API requests from Tesla with an
ExForce.Request{}
struct that can be composed into anExForce.CompositeRequest
orExForce.BatchRequest
. This could enable more explicit behavior specs as described in #26 and ideally allowing for easier switching out of the HTTP library.Started an initial mock of what the structs could look like here:
As the Composite Resource responses also have sub-responses an
ExForce.Response{}
like described in #25 would allow for aExForce.CompositeResponse
with the list ofExForce.Response{}
structs to be returned.As described, this would be a large surface area change. Maybe an interim option is to just use the current approach (
Tesla.Env{}
responses) and add Composite Resources functions like shown here. The trade-off being a lot of the Salesforce API implementation bleeds into the consuming application by having to build a compatible data structure for the resource (e.g.%{"allOrNone" => "true", "compositeRequest" => composite_requests}
) and parse out the response bodies.