Voting starts in March for the Drupal Association Board election.
This issue tries to provide an overview of current state of REST, HAL and it's issues.
Whenever REST is named it is about the rest.module or a json request.
Whenever HAL is named it is about the hal.module or hal+json request.
Other parts are modules serializer file and views.
@WimLeers has prioritised issues by title prefix: PP-# which means postponed-level. So to move stuff forward hunt for PP or PP-1 issues and their blocking issues
Current Open issues
Below are the parts providing HAL and REST from a REST client perspective.
How to use HAL or REST
There is a lot of noise on how to use HAL or REST. What operation supports either json and/or hal+json? What is the state of the current documentation?
REST API documentation
- We should provide the possibility to generate the API documentation.
- We need a mechanism to provide the current version of the API. A site update or adding entities or collections (views) needs a way to announce this changed API.
- We cannot provide 2 different API versions by design.
We have a weird interface to our content. Most APIs connect to their content type like article or post (aka Drupals bundle) instead of entity-type like node, comment or user. This causes a mismatch between rest permissions and entity+bundle access permissions too.
This can be through core cookie and basic auth in core. There is contrib oauth.
The REST access are not in line with the user permissions. Being able to post on /node (rest permission create node) can be blocked by missing ‘create article` permission.
It’s not clear what operation are allowed for REST request versus HAL request.
REST should support GET, POST, DELETE which is not yet confirmed or documented.
HAL should support GET, POST, PATCH, DELETE
BASIC_AUTH is broken and needs
One can create a Rest export display.
In HAL these are called collections.
The serializer supports field access but there is no display mode to filter out fields.
File is not a first-class entity yet. It lacks permissions, listing, CRUD pages. Should it be contrib or core. See https://www.drupal.org/project/file_entity
We currently want upload files as BASE64 encoded field value. Why? This seems not being explained and is not in line with other REST APIs. The workflow on ie https://developers.facebook.com/docs/php/howto/uploadphoto/4.0.0 is to ‘multipart’ post a file and use the resulting ID for further processing. They us http://php.net/manual/en/class.curlfile.php