I am trying to determine the best pattern to use to improve our use of a client's custom API endpoints. Using their endpoints can be a little screwy as they can use slightly different types of authentication (token vs api key often) depending on functionality and login state.
Right now we have a single function we call that resolves all of this and spits back an array containing details and an object from the endpoint. But the calling code must know the api path ahead of time (such as "customer/order-list" or "order/rates") before calling the function and then the functions have to deal with inconsistent data sets.
My thought process is to extend a base class with the core calling functionality and then each class that extends that will contain the various endpoint paths and how to work with them. I also want to hydrate consistent objects with the data returned so that the data I use throughout the system and pass to the front-end is consistent and functional. And I want to make that data exchange bi-directional.
I want this as extensible as possible as we add on new API endpoints that they are building for new functionality. We are pushing for more consistency on their end, but we still have to deal with legacy endpoints built in an ad-hoc way.
I looked at the Gateway pattern, but I don't think it quite fits the bill for what I need.
Does anyone have any suggestions for programming design patterns that might make this easier and more manageable for me and my team?
We are also building this in PHP (I know, other devs roll their eyes at the language, but I do not have a choice in the matter). So something that can be implemented with PHP 7's limitations would be preferred.
Thanks!
Aucun commentaire:
Enregistrer un commentaire