Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
As discussed in Proposing an alternative to application/vnd.drupal.ld+json, the new plan is to use HAL as the primary format for REST.
Step 1: Support GET with hal+json
To start with, we need to be able to respond to requests for application/hal+json and provide a JSON object back which contains all of the properties.
#1924220: Support serialization in hal+json
Step 2: Support POST/PUT/PATCH/DELETE in the HAL workflow
#1929632: Decide how to handle POST/PATCH when using HAL
#1931976: Support deserialization for hal+json (needs more language handling tests)
#1927024: Pass Link headers into Serializer
Comments
Comment #1
sunI'm glad that http://groups.drupal.org/node/283413 clarifies that this merely means to spank a new Serializer class onto the system. :)
At the same time, one potentially interesting aspect here is going to be:
Do we replace existing test coverage, or do we leave it as-is and only enhance it with a new format?
Answers will likely vary by potentially unforeseen details of module implementations... (specifically thinking of Views here) Pedantically/purely speaking, that would only be in favor of retaining existing test coverage for the current/previous format?
Aside from that, I can't see any architectural reason against this move. Whatever makes most sense to you experts will make most sense for everyone else. :) That said:
Thanks a ton for figuring out the best bet for Drupal and providing vision and direction! Well done!
Comment #2
Crell CreditAttribution: Crell commentedAs far as test coverage, I think anything that's generic to the Serializer pipeline or Rest.module stays. Anything specific to JSON-LD handling stays if we keep JSON-LD in core, and goes if we punt that to contrib. (That hasn't been decided yet.)
Comment #3
Anonymous (not verified) CreditAttribution: Anonymous commentedIt's pretty certain that we will not support deserialization for application/ld+json in core, so testing should probably switch to hal+json or json once we have a denormalizer committed for one of those.
Comment #3.0
Anonymous (not verified) CreditAttribution: Anonymous commentedAdded 1925618: Add documentation for REST link relations
Comment #3.1
Anonymous (not verified) CreditAttribution: Anonymous commentedAdded 1927024: Pass Link headers in to Serializer
Comment #4
Wim LeersDoes this mean that all of the Create.js-powered in-place editing will not be able to leverage JSON-LD?
P.S. the first link in the issue summary links to the WSCCI group instead of the "Proposing an alternative …" issue/document.
Comment #5
Anonymous (not verified) CreditAttribution: Anonymous commentedAs I explained in #1879898: Clean up EditService.js (preferably get rid of it in favor of RDFa) and get rid of Backbone.syncDirect in favor of JSON-LD and other places, CreateJS wasn't going to be able to leverage the work on that media type anyway. When I requested funding to develop the deserialization part of JSON-LD, funding for application/vnd.drupal.ld+json was committed but not funding for application/ld+json, which is what CreateJS would require.
Thus, switching from application/vnd.drupal.ld+json to application/hal+json does not affect CreateJS, since CreateJS was never going to use the former.
To be honest, I was never sure that using JSON-LD in the CreateJS case was actually wise for us. We want Drupal sites to have RDFa/microdata which uses Schema.org... this is essential for most sites. However, our internal data model doesn't neatly align to Schema.org, as I explained in #1813328: Enable literal handling in common RDF-ish domain models. Exposing both models in the RDFa, using one to communicate with Schema.org and using the other to communicate between page and server, seems like a disaster waiting to happen to me. On the other hand, only using the model that aligns to Schema.org introduces its own complications.
Comment #5.0
Anonymous (not verified) CreditAttribution: Anonymous commentedAdded 1929632: Decide how to handle POST/PATCH when using HAL
Comment #5.1
Anonymous (not verified) CreditAttribution: Anonymous commentedFixed link.
Comment #6
effulgentsia CreditAttribution: effulgentsia commentedPer #5, yes. However, that doesn't necessarily mean we can't make inline editing RESTful. Just like the Edit module currently adds a custom sync implementation based on submitting hidden forms, we can replace that with a custom sync implementation based on RESTful HAL. Bonus points if we can locate an existing implementation of that or entice others in the Create.js community to collaborate on one.
Comment #7
Anonymous (not verified) CreditAttribution: Anonymous commentedThe name of this was originally Hypermedia API Language, but then changed to Hypertext Application Language. Updating title to fully reflect the name change.
Comment #7.0
Anonymous (not verified) CreditAttribution: Anonymous commentedAdded 1931976: Support deserialization for hal+json
Comment #18
SpokjeThe
hal
module has moved out of Drupal Core and into a Contrib Module.Moving this issue to the Contrib Module queue.
Comment #19
larowlan