Drupal 8 is API eerst, maar wat betekent dat?

API stands for Applications Programming Interface. It is a set of clearly defined methods of communication between various software components (e.g.: Twitter has an API that makes it possible to post your tweets and present them on your website). API-first is all about making a central web service available that offers exchangeable data by a network to websites, mobile applications, wearables, etc. Drupal 8 now can be utilized as a REST API, this can be its single responsibility, but it can also offer Drupal platforms (with a Drupal frontend) the possibility to expose their data by REST API.

A successful case with Drupal 8

For a client, the Youwe Drupal team worked to replace their old internet and intranet website with Drupal 8. Due to its security reasons, the internet and intranet were split up in two server environments but were sharing the same codebase to be able to reuse functionality but most importantly to share content between the sites. The intranet wanted to have the ability to selectively synchronize content from the internet website, which then could be used inside the intranet. The internet is the owner of its content, this way of thinking was also translated in the architecture, by a one-way automated push mechanism that leverages CRUD functions (create, read, update and delete).

The way to go is API

A big part of this functionality was working on the custom client and REST API, which represented the content push mechanism. Of course, we have looked into different architecture approaches, but the conclusion was clear, a custom client and API would give us the most flexibility and efficiency in the content push mechanism. A good example of why this architecture was the way to go was the performance. Drupal 8 has by default REST endpoints available for each type of entity that could be used to sync data. The content that needed to get pushed was relating to a lot of other content (multiple sorts of entities) that were also required in the push. This would mean if we would use the default endpoints, we would be needing multiple requests for a single push. With a custom endpoint (API), we were able to bundle the content with its relations in one single request and process them all at once, which has a better performance impact.

The client needed to authenticate and queue its requests, while the API needed receive, validate, transform and process data. That sounds a lot, but luckily Drupal has a Queue API, Symfony Serializer Component, Guzzle Http Client and REST in the core, which are tools that make these requirements possible to develop. Our experience in this project leads us to the conclusion that Drupal 8 is a great system to build API's.

The API possibilities

The API in the project was coupled to the website but having a decoupled API can also be achieved due to the API-first architecture of Drupal 8. This means that Drupal can be used as an API and using other technologies for the presentation of the associated content. To have a better understanding of how this could be a possible solution for companies, we have summarized some possible data sources and destinations for a centralized Drupal 8 API:

        Sources:

• ESB (Enterprise Service Bus)
• Local files (e.g: JSON, XML, CSV, etc.)
• SOAP (Simple Object Access Protocol) service
• REST (Representational State Transfer) API
• MySQL database
  
  Destinations:
   

• SPA (Single Page Application) JS framework (e.g: React, Vuejs, etc.)
• Progressive decoupled application (e.g: integrated JS framework application inside a website).
• Website
• Webshop (e.g: Magento)
• Mobile applications
   

If you are interested in how to determine when to fully decouple, progressively decouple or couple Drupal 8, talk to our experts at Youwe. Contact them here. Or sign up for the Drupal 7 to Drupal anything webinar that is being held on the 12th of September. Sign up for the webinar here.