I think it's safe to say that most web applications are based on the request/response paradigm. PHP has never had a formal abstraction of these objects. One group is trying to change this: https://github.com/php-fig/fig-standards/blob/master/proposed/http-message.md
However, they sort of got side tracked on the issue of immutability. On the one hand, request/response object generally need very little change during their life cycle. On the other hand, the response object in particular often needs HTTP headers to be added.
Furthermore, immutability has never really caught on in the land of PHP.
What advantages do people see in using immutable request/response objects?
Let's suppose you are returning a json object.
$response = new JsonResponse($item);
Nice and simple. But it turns out that the request was a Cross-Origin Resource Sharing(CORS) request. The code that generates the response should not care but somewhere downstream is a process that will add the necessary Access-Control headers. Any advantage to keeping the original response and creating a new one with the additional headers? Or is it strictly a question of programming style.
The request object is a bit more interesting. It starts off the same:
$request = new Request('incoming request information including uri and headers');
The initial information should not need to be changed. However, as the request get's passed along there is often a need to add additional processing information. For example, you may have a url matcher which decides what action should be executed for a given request.
$request->setAttribute('action',function() {});
Actually executing the action is the responsibility of a down stream process. You could have a mutable RequestAttributesCollection which wraps the immutable request but that tends to be a bit awkward in practice. You could also have a request that's immutable except for an attributes collection. Exceptions tends to be awkward as well. Any experience on dealing with these sorts of requirements?