Joel Steidl
One of Drupal’s most important features is its ability to integrate seamlessly with other systems (CRMs, eCommerce Platforms, Event Management Platforms, etc). Drupal can expose data using modules like JSON:API, which are integral parts of Drupal Core. Moreover, it can also consume data and make HTTP requests using standard HTTP methods. This post will focus primarily on the latter—highlighting how a module named APITools simplifies the process for Drupal developers.
Background
In researching the history of HTTP request handling in Drupal, I discovered that drupal_http_request has been around since version 5.x. It was described as:
"A flexible and powerful HTTP client implementation that correctly handles GET, POST, PUT, or any other HTTP requests, including handling redirects."
Throughout Drupal versions 6.x and 7.x, drupal_http_request continued to be a go-to option, seemingly simpler than using PHP's CURL function directly—a tool that many developers find intricate. With the release of Drupal 8, Drupal::httpClient replaced drupal_http_request, granting developers access to Guzzle—the de facto HTTP client in the PHP community.
While httpClient/Guzzle is typically the preferred choice for HTTP requests, it's rare that any request happens without some form of authentication. Although OAuth 2 has emerged as a standard for API authentication, the specifics can vary considerably between different APIs. This variability doesn’t mean the principles of OAuth 2 aren’t followed; rather, the implementations differ just enough that attempts to abstract this functionality into a universal module have faced challenges. As a result, developers frequently find themselves writing slightly different code for each API integration to accommodate these nuances. APITools attempts to be just helpful enough in these sorts of situations without making too many assumptions.
Leveraging APITools for the Drupal Zoom API Module
I personally maintain the Drupal Zoom API module, and over the past year, Zoom has changed their authentication requirements. This challenge prompted me to explore the APITools module, maintained by my friend and colleague Alan Sherry. What attracted me most to APITools was its ability to offer configurable options for storing credentials and an extensible client plugin that routes all API requests through a specified authentication method. By using APITools, I significantly reduced the amount of code in the Zoom API module and quickly released a version 3.x, which is compatible with Zoom’s "Server-to-Server OAuth" authentication method. The configuration form and the majority of the API client are now provided by APITools, reducing the amount of code I’ll need to maintain in the Zoom API module.
If you, like me, maintain an API-focused contrib module or need a reliable HTTP client for one-off tasks, I highly encourage you to explore APITools. With a little setup time, you can configure your ApiToolsClient and start making requests effortlessly.
The fact is, there are numerous API client modules on Drupal.org, each tailored for different services. APITools offers an opportunity for a more consistent and efficient approach. I hope you'll check it out!
Getting Started / Examples
We've written some documentation on Drupal.org for you to reference. For a fairly complete example in the Drupal contrib space, checkout the client plugin that is part of the Zoom API module.
Additional Examples
We’ve created a repository with some various API clients that will hopefully help with getting started.
- Acalog - Simple api key implementation
- Auth0 - Access token request with audience and grant type
- Brandfolder - An example of using an sdk as a base with an apitools client wrapper around it
- Localist - Example of a static access token created by an administrator
- Sharepoint - Access token with audience / grant type, and “ext_expires_in” instead of “expires_in”
If you decide to use APITools, we’d love to hear about your experience in the blog comments below.