Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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