- Issue created by @brianperry
@grasmash has been inquiring in Slack about the possibility of this client supporting custom Drupal endpoints, and/or using the client to communicate with different types of APIs in a single project. Some copy and paste from past conversations:
> did you ever give some more thought to how one might use the json api client auth to hit custom drupal endpoints?
I'd really like to use the client for both json api and other endpoints, and have it handle the auth
particularly refresh token handling
> ...I'm using... custom fetch but I’d rather use Drupal client and not own the auth, caching, and url construction logic
> Notables features:
- Clear cache with keys,
- Allow cache to be bypassed per request
- Some methods make requests to JSON:API, others to custom endpoint
Nothing set in stone here, but after thinking about this I wonder if the 'custom Drupal endpoint' need could be solved by formal REST support and/or a rest-client package. Rest might feel like a bit of a misnomer given some of the associations with the core Rest module, but really this would be a generic package to communicate with Drupal via Rest rather than something exclusively focused on Drupal's core Rest implementation. It would support the core features of the client - caching, auth, etc and provide methods for GET, POST, PATCH and DELETE.
As for using multiple API types in the same project, substantially less clear on what a generic solution to this could be. Have previously created issues to make it possible for multiple clients to share things like authentication tokens and caches:
https://www.drupal.org/project/api_client/issues/3467668 →
https://www.drupal.org/project/api_client/issues/3467667 →
With that solved, it would then be possible to create some kind of higher level interface that can talk to multiple API types or contain multiple instances of clients, but use a single cache or authentication session.
Another possible way around this if the idea of Rest covering 'custom' endpoints holds water would be to actually add the GET/PUT/PATCH/DELETE methods to the base ApiClient class. JSON:API and GraphQL could even use those methods behind the scenes. I think this would make the ApiClient class usable in a way that @grasmash may have expected all along, but it also kind of locks these packages into RESTful APIs in a way. Will have to think more about that.
Active
Code