Problem/Motivation

Unable to pass $data/unserialized parameter containing request body to method 'put' of custom rest resource plugin. This type of request is not considered in \Drupal\rest\RequestHandler::createArgumentResolver when preparing list of available arguments for argument resolver. I suppose it was not considered due to https://groups.drupal.org/node/284948.

Steps to reproduce

  1. Implement a custom rest resource
  2. Implement method 'put' in the custom rest resource with parameter $data or $unserialized
  3. Make a PUT request to the custom rest resource

Proposed resolution

Change condition from

if (in_array($request->getMethod(), ['PATCH', 'POST'], TRUE)) {

to

if (in_array($request->getMethod(), ['PATCH', 'POST', 'PUT'], TRUE)) {

As I see from https://groups.drupal.org/node/284948, PUT was put off because it adds problems for dealing with rest resources for entities. But there are cases when developers create rest resources not dealing with any entity. In this case the developers are fully responsible for logic of such resources including method 'put'. They probably don't face problems described in https://groups.drupal.org/node/284948 . So, I think we should allow such developers to implement proper REST API with support of PUT. Also, PUT is allowed by the rest resource base class. So, I think we should keep support of PUT on the basic level of rest resources since it was already done.

Remaining tasks

No

User interface changes

No

API changes

No

Data model changes

No

Release notes snippet

Fixed argument resolver for methods 'put' and 'delete' of REST resource plugins so, that now it provides request body to parameters with name $data or $unserialized.

Issue fork drupal-3226944

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sergei_brill created an issue. See original summary.

sergei_brill’s picture

Status: Active » Needs review
daffie’s picture

Category: Bug report » Feature request
Status: Needs review » Needs work
Issue tags: +Needs tests

@sergei_brill: Thank you for your MR. I am changing the issue to a feature request as core has made the decision to not support put here and you would like to add it. Also the MR needs some automatic test to make sure that your change works and keeps working in the future.

drasgardian’s picture

The same issues also apply to DELETE requests.

Plugins implementing delete don't have access to the request body.

sergei_brill’s picture

Title: REST's Request handler doesn't resolve $data argument for put method » REST's Request handler doesn't resolve $data argument for put and delete methods
sergei_brill’s picture

Assigned: Unassigned » sergei_brill

sergei_brill’s picture

Version: 9.2.x-dev » 9.3.x-dev
Assigned: sergei_brill » Unassigned
Status: Needs work » Needs review
Issue tags: -Needs tests

Changed version to 9.3.x since now it is considered a feature request. Tests added, resolving of arguments $data/$unserialized in delete method added.

sergei_brill’s picture

Issue summary: View changes

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Niklan’s picture

Agreed that DELETE should receive $data / $unserialized values.

According to RFC 7231, DELETE method can have body. MDN also says:

Request has body May

The current solution is to accept $request argument and get body from it, the problem is, that if resource supports for multiple content types, it must implement something like \Drupal\rest\RequestHandler::deserialize() to handle multiple types.

Workaround:

  public function delete(Request $request): ModifiedResourceResponse {
    // Considering that request done with Content-Type: application/json.
    $data = Json::decode($request->getContent())
    …
  }

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

ahana.kundu’s picture

ranjith_kumar_k_u’s picture

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Janvi Dasani’s picture

Added patch against #16 in 10.1.x

smustgrave’s picture

Status: Needs review » Needs work
Issue tags: +Needs Review Queue Initiative

Can the MR be updated for 10.1 please
Hiding files as the issue appears to be worked in the MR.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.