@Ilya_user OK. So in that case, you’ll need to write separate classes to interact with each post office company’s API. You’ll make your life easier if you make these classes conform to a common interface. Then when the end user picks a post office, you can use the corresponding implementation to do whatever logic you need to do:
interface PostOfficeService
{
public function getDeliveryQuote(Address $address, Dimensions $package): Money;
}
class PostOfficeOneService implements PostOfficeService
{
public function getDeliveryQuote(Address $address, Dimensions $package): Money
{
// Code here to get quote from post office #1
// to get delivery quote for given address and package dimensions...
}
}
class PostOfficeTwoService implements PostOfficeService
{
public function getDeliveryQuote(Address $address, Dimensions $package): Money
{
// Code here to get quote from post office #2
// to get delivery quote for given address and package dimensions...
}
}
You can have some sort of manager class that returns the correct implementation based on the user’s selection, and calls the relevant method:
$service = $postOfficeService->getServiceFor($request->input('post_office'));
$quote = $service->getDeliveryQuote($address, $dimensions);
As you can see, if you use a single interface for all services, then your code doesn’t need to change depending on which post office is selected. You can also add new implementations, change existing implementations if a post office updates its API, etc.
You’ll see I’ve also used objects for things like Address and Dimensions. These would be classes in your application to make things consistent. Pretty much DTOs. I also standardise the output to just be a Money instance, rather than each service returning results in different shapes and formats depending on which service was called.