Question: Best Practice for Reusing Request Classes for Multiple Endpoints in Saloon

[vijaythecoder]

I am working on an integration using the Saloon package and have encountered a scenario with the following endpoints:

• GET /customers - retrieves all customers
• GET /customers/{id} - retrieves a specific customer by ID
• POST /customers - creates a new customer

The code for each request is quite similar, with the main differences being the inclusion of an ID for the specific customer retrieval and attaching a body for the POST request.

I am wondering if there is a better way to utilize the same request class for these endpoints, or if it is recommended to have a separate request class for each endpoint. Specifically, even if I use a different request class for POST, the GET requests for retrieving one or many customers from the /customers endpoint share a lot of similar code.

What are the best practices in this scenario? Should I refactor to use a single request class with conditional logic, or is it better to keep separate classes for clarity and maintainability?

Any advice or examples would be greatly appreciated. Thanks!

[sinnbeck]

I personally just implemented this myself in a project and chose to go with a class for each. That make it way easier to figure out exactly what was needed for to work properly. For instance my GetAllCustomersRequest needed caching so I could just apply that to that single class. And my FindCustomerRequest needed to have the id injected in the constructor, so I could add that. And finally my CreateCustomerRequest needed the HasJsonBody trait, so could just add that here.

And all places where it was used, it was VERY clear exactly what was happening.

Finally it made testing easier, as I could have mocks for two different classes, in the same test. For instance I had code, that got all customers first, and then did a further look up on a single customer.