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

Step 3: Help consumers use the API

Comments

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

I'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!

Crell’s picture

Crell commented

As 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.)

Anonymous’s picture

Anonymous (not verified) commented

It'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.

Anonymous’s picture

Anonymous (not verified) commented
Issue summary: View changes

Added 1925618: Add documentation for REST link relations

Anonymous’s picture

Anonymous (not verified) commented
Issue summary: View changes

Added 1927024: Pass Link headers in to Serializer

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

Does 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.

Anonymous’s picture

Anonymous (not verified) commented

As 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.

Anonymous’s picture

Anonymous (not verified) commented
Issue summary: View changes

Added 1929632: Decide how to handle POST/PATCH when using HAL

Anonymous’s picture

Anonymous (not verified) commented
Issue summary: View changes

Fixed link.

effulgentsia’s picture

effulgentsia commented

Does this mean that all of the Create.js-powered in-place editing will not be able to leverage JSON-LD?

Per #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.

Anonymous’s picture

Anonymous (not verified) commented
Title: [META] Hypermedia Application Language (HAL) support » [META] Hypertext Application Language (HAL) support

The name of this was originally Hypermedia API Language, but then changed to Hypertext Application Language. Updating title to fully reflect the name change.

Anonymous’s picture

Anonymous (not verified) commented
Issue summary: View changes

Added 1931976: Support deserialization for hal+json

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev
spokje’s picture

spokje
Primary language Dutch
commented
Project: Drupal core » Hypermedia Application Language (HAL)
Version: 9.3.x-dev » 1.0.x-dev
Component: base system » Code
Issue summary: View changes

The hal module has moved out of Drupal Core and into a Contrib Module.
Moving this issue to the Contrib Module queue.

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
commented
Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.