PSR-7, the HTTP message interfaces opened a new door of creating modular applications.
Sadly many of the PSR-7 implementations added many helper methods.
So if someone is creating a library that needs a PSR-7 implementations they tie the particular library with the PSR-7 implementation and use these convinient helper methods.
So was PSR-15: interfaces for HTTP Middleware and PSR-17: interfaces for HTTP Factories was proposed.
When creating a module one of the most challenging part is how to serve the javascript, css and images. We are going to use hkt/psr7-asset which is a fork of Aura.Asset_Bundle . What you want to do is only map the path to the assets folder.
Whenever I get some time, I try to learn and experiment on different frameworks. I would like to stay away from pin pointing to the frameworks I have looked, so they don’t feel bad.
Long live components # Components are awesome!. You can plug your favourite components to any system. Thank you composer. One strong preference choosing a framework was
This post is a thrive to learn, and not to show anyone is incorrect. Feel free to share your thoughts.
Lukas Kahwe Smith was having a nice post RESTing with Symfony2
Quoting a few words from the post on REST
DELETE and 404 # I started my talk on RESTing with Symfony2 with an introduction to REST itself. On slide 7 of my talk I explained the concept of “safe” and “idempotent” HTTP methods. Many people were surprised when I explained that DELETE should be idempotent, meaning that sending a DELETE request to a resource that has been removed should infact not return a 404.
Comparing a software X with Y will not make anything worst, but makes it better. But many of them will think it as a promotional stuff. It is not anyones’s problem. Some like to build it that way, some like the other way.
So I am not comparing X with Y here.
Not talking about package like Guzzle:
I am not mentioning building something like Guzzle, which is a framework that includes the tools needed to create a robust web service client.