Base Distribution - Work Package #45088: Improved REST support
More flexible parsing of body arguments
Parsing of body arguments (e.g. xml, json) currently takes place in Http\Request and is hard-coded there.
Besides from being a bit buggy (e.g. you currently have to specify two root nodes like <root><product><title>changed title</title></product></root> where a common REST request would expected to be just <title>changed title</title>) the behavior can't be influenced easily because it happens so early in the request handling.
[!!!][FEATURE] Flexible parsing of request body arguments
Parsing of body arguments (e.g. xml, json) currently takes place in
``Http\Request`` and is hard-coded there.
This change extracts the decoding of body arguments from the request
class to a TypeConverter that is invoked by the ActionRequest only
The TypeConverter is referred to via a new marker interface
``MediaTypeConverterInterface``. In order to extend the media type
conversion, this interface has to be implemented by a custom
TypeConverter and set as default implementation in Objects.yaml::
This change also deprecates ``Http\Request::createActionRequest()``
in favor of ``$actionRequest = new ActionRequest($httpRequest);``
This is a breaking change in the rare case that
``Http\Request::getArguments()`` is expected to contain the parsed
request body already.
If you require to access those body arguments either use/create
an ActionRequest instance or parse the body arguments manually,
for example by using the PropertyMapper.
[BUGFIX] Properly merge request- and routing arguments
The "HTTP Components" feature (#52064) introduced a regression that
makes it very difficult to create RESTful services with Flow.
The problem is that the ``matchResults`` from the routing framework
override the arguments of the HTTP request instead of being
This change moves the merging of request- and routing arguments from
the ``ActionRequest`` to the ``DispatchComponent`` reducing the
complexity of argument merging and fixing the behavior of routing
values overriding the request arguments.
Note: This is a breaking change if you relied on the incorrect
behavior but it's not marked as such because there is no released
version that contains the regression.
#1 Updated by Bastian Waidelich about 7 years ago
Also see Marco Falkenbergs comment on #37604:
Some additional thoughts...
Processing of request content¶
In case of RESTful webservices the processing of the request's content should be more advanced and extensible. For now i.e. XML data is poorly treated by just converting over a SimpleXMLElement to an array. I know that this lack is mentioned by Robert in the comment, but there is no according issue tracker.
The funny thing is we have everything to make this work, because we have the property mapper with its type converters and their customizable configurations. Why don't allow IANA types AND class types as source types for a type converter? It's just pulling the responsibility for the property mapper one level up. Then you can implement the handling of XML data with your own XML type converter that i.e. accepts the source types 'application/xml', 'DOMNode', 'DOMElement', 'DOMDocument', 'DOMText'.
I tried it out and it works!