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 in to Serializer

Step 3: Help consumers use the API

Comments

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!

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

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.

Issue summary:View changes

Added 1925618: Add documentation for REST link relations

Issue summary:View changes

Added 1927024: Pass Link headers in to Serializer

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.

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.

Issue summary:View changes

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

Issue summary:View changes

Fixed link.

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.

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.

Issue summary:View changes

Added 1931976: Support deserialization for hal+json