Why I should abstract HTTP messages?
If you have ever used a PHP web development framework, you may have noticed that they all keep an internal representation of Http request and response.
In other words, they create PHP objects populated mirroring the same data put in the well-known global variables $_GET, $_POST, $_COOKIE… (for the request), and the body content that should be echoed by the browser (for the response).
It may not be immediatly clear why you would need this abstraction layer. I’ll try to make it clear in this article.
The Internet is simple
The web is built around the Http protocol, which works in a really simple way. You ask the server for a resource, and it gives you a response. You use the browser either to send the request and to view the response.
As a web PHP developer, the exciting part is that any thing in the “Server” box is under your full control. Your PHP script can read the request coming from the client browser and send back the response you decide.
The developer job
You can write any kind of web application around these concepts, no matter how complicated the server box is internally.
If you’re a good developer you may know the importance of testing. But also, if you never wrote tests, you may want to debug your application behaviour under certain circumstances.
What is the response of my system, for example, in case of a POST request sending the wrong username and password? To try this case, you should really make such request through your browser. This is possible, though inconvenient: you may also have test cases harder to simulate or impossible to cover. Maybe you want to check your system response when you’re sending a 50MB file to the server, or test a request sent in a specific day in the future.
The problem here, is that the request and response are outside of the server box and you can’t control them. The easiest solution is to transform these objects into a PHP representation:
Now, the request and response objects are inside the server box. In the normal flow, the request is populated by the Http Request sent by the browser, and the response created by the application will be used to create the real Http response for the browser.
I called them “Psr7 Interface” in the slide because I am specifically referring to the Slim PHP framework, which adheres to the PHP-FIG standard. However, the concept of abstraction of Http messages is not tied to any standard.
In this scenario, it is easy to build any request programmatically and trick your system into thinking that the request arrives from the browser. For it, there is no difference at all. And in the same way, the response may be analyzed and not sent to any client.
The PHP-FIG Psr7 standard
The PHP community is great and in the last years a huge effort has been made to standardize behaviours to make easier communication between different libraries. Psr’s are the result of a lot of discussions and point of views, and may be not the best way of doing things (some of the recommendations have been deprecated yet, in favor of new ones).
I think following the psr’s recommendation, though, is a way to touch the problems they addresses and enter the discussion. An example is this interesting article about the psr-7 problem with immutability for the response and request objects. This is a design choice that may impact your application performance and memory usage.
Of course you don’t need to build your own implementation of the psr7 — there are a lot of them yet, ready to be used. You may also use another representation of Http messages that does not follow the psr-7 recommendation, like the Symfony’s HttpFoundation component.
Never lose the control of what you’re doing. Inside the server box you are God. Test! Use your power and fake your own system. Yay!
A list of PHP frameworks for web development
The PHP-Fig psr-7 standard
Article discussing issues about the psr-7
The Symfony Http foundation component
The Slim framework guide page about the psr-7 implementation
A nice overview of Http protocol from the MDN web docs