Pantheon supports running WordPress and Drupal as an API (Application Programming Interface) for the backend of headless sites, which enables the CMS to interact with external frontend applications over HTTP requests.
For example, a mobile application that uses the
DELETE HTTP methods to perform CRUD operations on a CMS's database .
WordPress and Drupal are traditionally monolithic CMSs, meaning they serve as the frontend and backend of a site. Decoupled architecture (headless) is a development model that uses a CMS to manage content in the backend with a completely separate frontend component to render that content in the browser.
Some key differences of decoupled architecture include:
Presentation can be handled in a variety of ways, from interactive JS frameworks like Angular, to static generators, to mobile apps, or even another CMS. Multiple frontends can peacefully coexist.
Content Via Web Service API
The content for the site is accessible via a web-service API, usually in a RESTful manner and in a mashup-friendly format such as JSON.
CMS Backend and Database
There is a traditional database-driven CMS which editors use to maintain the content for the site, usually via the same admin interface as always.
Backend APIs running on Pantheon take advantage of the following platform features for optimal performance:
Running WordPress and Drupal as an API on Pantheon can be done on any Drupal or WordPress upstream. The process to create, update core, and launch a backend API on Pantheon does not deviate from the standard procedures.
Since WordPress 4.7, the WordPress API is included as part of core. There's no action needed to expose the API on Pantheon. Explore default routes and endpoints like
/wp-json/wp/v2/posts in your browser:
We recommend using a trusted browser extension to format the JSON response from the API so it's easier to read.
Refer to the Rest API Handbook from WordPress.org's Developer Resources for full documentation on this web service.
With the release of Drupal 8, Web Services have been implemented to core through different modules:
_linksfor link relations (also used by Github's Pull Request API) and
_embeddedfor embedded resources. The HAL hypermedia format can be encoded in both JSON and XML.
By default, not all resources or endpoints are enabled. You may need to individually enable
DELETE operations for each web service like node entity or user. Read about the overview and steps for the configuration on the API overview page.
There is a contributed module called REST UI which provides an admin interface for enabling or disabling resources, serialization formats and authentication providers. Use this to quickly manage and save your configuration.
Because Views is also part of core, you can make a JSON resource once REST and Serialization modules are enabled. Just create a view and select "REST export" as its display type. Name the path as you like.
rest/views/articles/1) for filtering results.
To create a node entity, we must send a
POST request to
/entity/node with the
Content-Type header set to
application/hal+json and declare the required type and title fields in the request
If you have Basic Authentication enabled, you need to set headers
PHP_AUTH_PW to authenticate as our user.
Web Services are implemented through various plugins in Drupal 7.
The service module has several integration features, and other web service formats. It also has several supporting modules that extend the Drupal 7 functionalities made available to the API.
While not a REST API service by itself, you can create a JSON view using the Views Datasource module.
We recommend using one of the following Chrome extensions to debug HTTP requests: