1. Это хотел решать через Route::parameters()
2. Форматирование чего?
3. Над этим не думал даже, но это в 100% лишняя завязка, вот почему:

есть rpc протокол, где мы отправляем практически всегда следующие ответы:
{id: 1, result: {...}, error: null}
всё, что мы возвращаем из экшенов летим в result.
как быть, если хотим менять id? а если error? пишем кастомные обработчики этих моментов с еще раз кастомным Response? ну такое.
хочешь стандартизировать формат ответа, используй объект, который делает эту работу.

о чем я: если нужно всегда делать {id: 1, result: {...}, error: null}, тогда делаем в контроллере
return RPCResponseObject($data, $id, $error); - это явно и понятно. опять же, если это делать в каждом экшене, то это будет система, а нам нужно избегать систематических лишний действие - оборачивает в middleware и всегда возвращаем из контроллера массив с максимум 3 элементами
return [$data, $id, $error];
Как правильно обернуть это, чтобы дальше конвертить в Response нужно обдумать.

ну, это имхо)

Middleware как раз и предназначены для "систематической работы". Кроме оборачивания, в ответе может присутствовать одинаковая часть для всех роутов или группы, допустим настройки, как бывает в спа передают. Это тоже легко прикрепляется в моем решении.

пишем кастомные обработчики этих моментов с еще раз кастомным Response?  - ты не разобрался как оно работает, мы можем прозрачно работать с сырыми данными и для этого не надо еще раз ничего сосздавать, работаем с тем же ответом. Сделали $response->getData(), поменяли данные, вернули $response->withData(). Таким образом данные формируются по всему стеку, так как доступны всем мидлтварям, а в стрим они уже преобразуются в эмиттере с помощью форматтера.

А еще ты не учитываешь, что основным экшином может быть не метод контроллера, а, например, коллейбл или класс реализующий мидлтварь. Из них ты как сырой массив вернуть собираешься?

Вернуть-то понятно как :) return-ом :)

И обработать понятно где - в callable middleware.

Но да, минусы видны...

А если мидлтварь?

Умгу, тут начинаются проблемы.

Но, конечно, короткий синтаксис аля return $data подкупает...

Route::create('/', SiteIndexAction::class)->name('site/index') и усе, массив ты с нее не вернешь. А с DeferredResponse легко

Ну а сейчас это длинный?
return $this->responseFactory->createResponse(200, '', $items);

Ну, длиннее :)

И там и там одна строка. Я понимаю, если там бы еще куча действий дополнительных было, так нет же)

Ну да, не столь критично

@roxblnfk с тебя тогда эксперимент со стримами, ок?

Можно сразу у меня с ветки со стримом скопировать, все ж не с нуля писать

@xepozz а с тебя как смёржим, перестроить REST чуть, хорошо?

Плюс