On the Pineco.de blog they've posted a tutorial for those out there using Laravel's request and response handling to add in macros to modify the information in the request/response based on custom logic.

We’ve already talked about the power of the collection macros. Now let’s take a look at the request and response macros as well to explore the possibilities that extending their functionality offers.

The tutorial starts by showing the creation of a filter request macro. This macro pulls the information out of the response and removes data that contains null values. Similarly, they show how to create a toSpecialFormat macro on the response, formatting the response as a JSON message rather than normal output.

In a post to his site Matthew Weier O'Phinney shares some notes about GraphQL usage that he's gathered over the last week or so of working with it.

The last week has been my first foray into GraphQL, using the GitHub GraphQL API endpoints. I now have OpinionsTM.

The promise is fantastic: query for everything you need, but nothing more. Get it all in one go. But the reality is somewhat... different.

He talks about his experience working with the results and the amount of data manipulation that was required to actually get at what he wanted. He shares the query he used, the result the API provided and what he ultimately wanted. He also mentions the less than useful documentation, issues with pagination and an update based on comments of pulling data from the GraphSQL API versus the REST API.

Following up on his previous Content Security Policy and Laravel posts, Christoph Rumpel continues the series and looks at how to fix his site's integration with Turbolinks. Turbolinks makes it easier to load only partial portions of a site when links are clicked rather than reloading the entire page.

My last week was all about Content Security Policy (CSP). It was an emotional rollercoaster. I loved the concept of CSP and was happy that I managed to integrate it into my site. But then I noticed that caching and Turbolinks weren't working anymore because of the CSP nonces. I had to turn them off. Then yesterday, I found a way to use CSP nonces with the Laravel Response Caching package. I was super excited about it.

Still, Turbolinks weren't working.

He starts by describing the issue with the CSP policy and the Turbolinks tool, mostly that the nonces in the response header no longer match the ones in the embedded script tags of the new content. He ended up finding a solution in the hash-algorithm CSP directive. This allowed him to create a hash of the requested script and validate it without the need for a nonce. He includes the code changes to his previous Laravel Response Cache middleware setting this hash-algorithm directive on the script tag output.

Christoph Rumpel has posted a guide for the Laravel users out there that have wanted to implement a Content Security Policy (CSP) in their application. A CSP helps to prevent cross-site scripting issues by locking down the images, scripts, resources, etc. that can be used in your application.

Caching is lovely, and the Content Security Policy is incredible. But when you put them together... Let me show you the problems I encountered, and how I fixed them.

He starts by describing the setup he was working with and improvements he was making (using the Spatie Laravel ResponseCache package to improve the performance of his site). As a part of the refactor he decided to implement a CSP but had an issue where the nonces on the included scripts didn't change like they did in development. To resolve the issue he created a middleware that takes the response and, after calling the other middleware, append the header to the response instance. Full code for the solution is included in the post.

On his Medium.com site Muhammad Zamroni has a quick tutorial posted showing how to create a system that will [stream CSV data] in a Laravel application (https://medium.com/@matriphe/streaming-csv-using-php-46c717e33d87) back to the waiting client.

In one of our application, there’s a need to get list of data from a service. This data is used to generate report by background process, resulting a XLSX file that can be downloaded or attached to email. This service (an API) is written in Laravel. The background process is also written in Laravel. Both service are hosted in different server.

We pull data from MySQL and simply send the response in JSON to be easily parsed. The problem we encountered was the amount of data.

The main issue was the memory that it required to pull in all of the data and work with it. Based on some suggestions from another article they decided to switch from JSON to CSV for output and use the chunk handling to process pieces of data at a time. He includes the code for the controller that shows the use of chunk and a manual file pointer to push the data into the response 1000 records at a time.

In a new post to his site Matthew Weier O'Phinney, lead developer on Zend Framework and representative in the PHP-FIG, covers the acceptance of PSR-15 by the group. PSR-15 relates to the creation of server request handlers and middleware that can use PSR-7 formatted messages.

Yesterday, following a unanimous vote from its Core Committee, PHP-FIG formally accepted the proposed PSR-15, HTTP Server Handlers standard.

This new standard defines interfaces for request handlers and middleware. These have enormous potential impact on the PHP ecosystem, as they provide standard mechanisms for writing HTTP-facing, server-side applications. Essentially, they pave the way for developers to create re-usable web components that will work in any application that works with PSR-15 middleware or request handlers!

He starts with a bit of background around the initial idea of the standard and some of the discussions that came up around it. The initial draft of the standard was modified to more correctly handle issues around response modification and the use of "handlers" for request/response manipulation. He then covers the final version of the standard, defined in the standard's documentation and enforceable via the psr/server-handler interface. Finally he covers how to use this to create re-usable middleware and an example using Expressive.

Sergey Zhuk has a new post to his site showing how to define and use middleware in your ReactPHP application.

What exactly is middleware? In real application when the request comes to the server it has to go through the different request handlers. For example, it could be authentication, validation, ACL, logger, caching and so on. Consider the request-response circle as an onion and when a request comes in, it has to go through the different layers of this onion, to get to the core. And every middleware is a layer of the onion.

He starts off with a simple example of a ReactPHP-based server that just responds to all requests with a "Hello world" message. I includes some logging functionality that he then refactors out into middleware. This logging records the HTTP method used, time of the request and the URL requested - all things the code can get from the request object. Code is included showing the refactoring out to the middleware and injecting it into the ReactPHP application. He then updates it to check for the existence of a file and, if so, returns the results as a stream. Finally he covers updates to the response inside the middleware, changing the HTTP status code and content returned based on the results of various checks.

For those dealing with APIs on a daily basis (or even the casual API-er) you'll find this post from Phil Sturgeon interesting. In it he takes on the opinion that's shared in this article from Pakal De Bonchamp that "REST is the new SOAP".

Enough people have asked me about the article REST is the new SOAP that I felt it justifies a write up. [...] The entire article is full of common misunderstandings about REST and HTTP. Despite dedicating my career to trying to educate people through these confusions, they continue to be rife. Clearly I am not being loud enough, writing effectively enough, or doing a good enough job. That is the frustration you might hear in my writing, but nothing is aimed at the author.

In his post Phil goes through the original article, pulling out quotes and responding to them one at a time. He shares opinions on HTTP verb operations, REST architecture, HTTP response code usage and the use of caching and statelessness in the API functionality.

For those dealing with APIs on a daily basis (or even the casual API-er) you'll find this post from Phil Sturgeon interesting. In it he takes on the opinion that's shared in this article from Pakal De Bonchamp that "REST is the new SOAP".

Enough people have asked me about the article REST is the new SOAP that I felt it justifies a write up. [...] The entire article is full of common misunderstandings about REST and HTTP. Despite dedicating my career to trying to educate people through these confusions, they continue to be rife. Clearly I am not being loud enough, writing effectively enough, or doing a good enough job. That is the frustration you might hear in my writing, but nothing is aimed at the author.

In his post Phil goes through the original article, pulling out quotes and responding to them one at a time. He shares opinions on HTTP verb operations, REST architecture, HTTP response code usage and the use of caching and statelessness in the API functionality.

Sergey Zhuk has kicked off a series of posts to his site showing how to create a ReactPHP memcache client that can work as a streaming client for your PHP application rather than single get/set requests.

Before writing any code we should think about our future client’s API: how we are going to use it [and] what methods it is going to have.

The client is going to be used in ReactPHP asynchronous ecosystem, so I’m going to provide a promise-based interface for it (when methods return promises). Also, we are building a streaming client. Under the hood, we will open a socket connection and use it as a stream. The client itself will be a wrapper on this binary stream communication. That means that it is our job to manually parse Memcached protocol to write and read data with sockets. So, having all of this in mind, let’s start.

He then starts in on the development of the base for the client including the factor class that will create the client (connector) with the provided Loop instance. He includes an example of this in use to create the client and point it to a local memcache server. Next he creates the client class that will use the stream to send requests and a parser to work with the responses and resolve actions that need to be taken based on their contents.