🇺🇸United States @JBHUTT09

JBHUTT09 → created an issue.

Okay, I've got the code written and working. I'm going to try and create a fork. This is the first time I've done this, so please bear with me if I do something wrong.

JBHUTT09 → created an issue.

Okay, so I've come to the conclusion that I've been barking up the wrong tree and that the best solution would be to allow the default response format to be set in the admin UI. That would sidestep the issue entirely.

So I've just now come back to this after a year of other projects and I think I've found a solution, though I'm not sure if it violates any conventions.

My solution is to pass the format argument in the post body instead of in the query string. I've implemented two approaches for this solution. They both modify Drupal\subrequests\Blueprint\BlueprintManager::parse() and check for a format key in the input and apply that format to the Request object which determines the response format in Drupal\subrequests\Controller\FrontController::handle(). The default will be multipart/related just for as much consistency with the existing module as possible, though I would personally expect the default format to be JSON since this is for the JSONAPI.

This is the first:

public function parse($input, Request $request) {
    $decoded = $this->serializer
        ->decode($input, 'json');
    $format = $decoded['format'] ?? 'multipart-related';
    unset($decoded['format']);
    /** @var \Drupal\subrequests\SubrequestsTree $output */
    $output = $this->serializer
        ->denormalize($decoded, SubrequestsTree::class, 'json');
    $request->setRequestFormat($format);
    $output->setMasterRequest($request);
    // Forward the Host header to place nice with decoupled routers.
    $this->forwardHeader('host', $request, $output);
    return $output;
}

All this does is check for the format key and unset the key before the input is passed along to the denormalizer.

The second, and my preferred is:

public function parse($input, Request $request) {
    $decoded = $this->serializer
        ->decode($input, 'json');
    $format = $decoded['format'] ?? 'multipart-related';
    $subrequests = $decoded['subrequests'] ?? $decoded;
    /** @var \Drupal\subrequests\SubrequestsTree $output */
    $output = $this->serializer
        ->denormalize($subrequests, SubrequestsTree::class, 'json');
    $request->setRequestFormat($format);
    $output->setMasterRequest($request);
    // Forward the Host header to place nice with decoupled routers.
    $this->forwardHeader('host', $request, $output);
    return $output;
}

This approach changes the payload format and places the subrequests into their own subrequests key. I think this approach is cleaner as it keeps the different parts nice and separate. It also allows for flexibility as it would be simple to add more keys for future functionality. But I'm not sure if this violates some convention that influenced the original payload structure to be just an array of requests.

I have no idea how to do things like generate patch files or propose changes. Maybe I'll look into learning that, but for now at least I wanted to share my findings in case they help others.