Composable Request/Response Structs to use Composite Resources

[zblanco]

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.

[chulkilee]

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