The future of REST in Drupal
Fully and partially decoupled applications are becoming more and more popular. Many times in this scenario Drupal is being used as a content modelling application with excelent editorial tools. That means that Drupal is used to manage content and expose it to the world through an HTTP API.
Drupal 8 comes with the REST and HAL modules in core, that allow you to expose really quickly any entity type in your system. In minutes you can have your back end ready to start making requests using the front end framework of your choice. It is then when you realize several missing key features. These features are geared towards performance, to address the classic issues with REST implementations.
In my experience building large decoupled applications like The Tonight Show with Jimmy Fallon, SNL 40th anniversary and NBC.com, I have identified the following missing pieces for Drupal 8.
- Versioning: every release of the consumer is locked to a version of the API. That version of the API remains invariant through time.
- Sparse fieldests: the consumer chooses what fields they want back, instead of every single field.
- Resource composition: the consumer requests the output of certain relationships to be included in the response, avoiding extra requests.
- Filters everywhere: the consumer finds content based on conditions on the returned attributes and relationships.
- Listings: if no particular item is requested, then a list of items should be returned.
- Pagination: the consumer requests lists of items and recieve a paginated list.
In this session I will assume that you come in with a basic understanding of how a decoupled architecture works. You will walk out the session with an understanding of what needs to happen to turn your API into a performant API.