In earlier discussions, we had tried to map out how we would handle different HTTP methods within Drupal. As often happens, though, no plan survivies first contact with the enemy. We've had to make some adjustments along the way, but some of them have been bigger than others.
Perhaps the biggest stumbling block has been the HTTP PUT method. Based on our experience so far, the REST team has decided the best course of action is to simply drop support for it from the rest.module in Drupal 8.
In the original plan, we had determined that the semantics of PUT were such that we could still support it for updating of entities. It would be tricky, but we could. Most of the questions revolved around the idea of revisioning, and we figured out how to map the URIs such that revisioning made sense with PUT.
Unfortunately, we've run into other issues with PUT while implementing the rest.module. Specifically, the requirement that PUT's body be the value to be set at that URI, and that would then be returned by a GET to that URI. For simple binary objects (files) or simple data objects, that's fine. However, Drupal's entities are not simple data objects. They're actually really complex, especially when you consider that in Drupal 8, every entity is likely to contain at least one relationship to another entity. (An Entity Reference in Drupal parlance, or a Link in Hypermedia-tongue.) Consider nodes, where every node will, at minimum, have a Link to its authoring User. Then mix in taxonomy and you have potentially several more.
That is no issue when representing an entity in HAL when responding to a GET request. HAL, which we'll be moving to for our primary format, has a standard way of handling links to other entities and for embedding entities with the main object for improved performance, and they're reasonably straight forward to generate.
For PUT, however, it becomes more complicated because the PUT would be required to include exactly the Link relations that we would then get back on a GET. That's not always feasiable, especially given how inter-related the Links are in Drupal. PUT's semantics, however, say that we could not ignore them, and the resulting changes to Drupal's data store could be... complicated.
Another issue is field permissions. Klausi has been working on figuring out field permission support when doing RESTful updates for a while, but it's challenging. And, really, impossible to do without violating the rules of PUT. As soon as you enable field-level edit restrictions, you cannot PUT an entire node object at once unless you have permission to edit every field. If you don't have that permission, there is no situation in which PUT can be legal since PUT cannot update only some fields. It must be the whole object.
By contrast, PATCH and POST do not have these issues. POST's semantics are, largely, "you define it". We can define handling of field permissions however we want, and can ignore any Link relations that are problematic to process. PATCH, while less widely used, naturally allows for only partial updates and therefore makes field permissioning much easier to support.
But why not just use raw application/json for PUT instead? We considered that, and it's apparently a not uncommon practice in the HAL world, but realized that in order to do it properly given Drupal's highly inter-connected data model we would need to still include some portions of the HAL structure anyway, at which point we may as well just use HAL, at which point we're right back at dealing with PUT.
So, the REST team has concluded that PUT is simply more trouble than it's worth at this point. We therefore propose to drop PUT support from the rest.module entirely and rely on POST and PATCH for write operations.
That does not, of course, in any way preclude someone from further developing the PUT question in contrib. Nor does it preclude someone from offering their own non-rest.module-based or non-entity-based Hypermedia API through Drupal that supports PUT. All of the routing plumbing is there to support it if someone wants. This applies only to the rest.module as it appears in core.
We're pretty well sold on cutting our losses on PUT, but I will leave this discussion open until 4 March in case someone can offer a strong alternative.