On the TutsPlus.com site today there's a new tutorial where they spotlight one of the components in the Symfony framework: the routing component. The tutorial outlines some of the basics about the component, installing it and putting it to use.

The Symfony Routing Component is a very popular routing component which is adapted by several frameworks and provides a lot of flexibility should you wish to set up routes in your PHP application.

If you've built a custom PHP application and are looking for a feature-rich routing library, the Symfony Routing Component is more than a worth a look. It also allows you to define routes for your application in the YAML format. Starting with installation and configuration, we'll go through real-world examples to demonstrate a variety of options the component has for route configuration.

The tutorial starts with the commands to get the component installed (via Composer) and other related components for YAML parsing, HTTP handling and configuration parsing. It then provides examples of:

• setting up the instance and defining some basic routes
• how route matching works
• loading routes from a YAML file

The tutorial finishes with an example of an "all in one" router that pulls in the route configuration and creates a new Router instance with them ready and waiting to handle requests.

Nikola Posa has a quick post to his site showing how to use a mocked up HTTP request handler - in this case Guzzle - for testing web API clients. These scripts make live HTTP requests to remote APIs as a part of their functionality but this presents a dilemma for testers. Unit tests should not reach out to external sources...and that's where the mock comes in.

Whether you're writing a client for your own web API to offer it to users or you're simply implementing integration for a 3rd-party API in your system, it is important to test it to make sure your client is capable of handling actual API responses correctly.

Testing web API clients is mostly about checking how they deal with responses received after sending requests to API endpoints, and for your unit tests, you introduce test doubles to simulate API calls instead of executing real HTTP requests.

He starts with a quick note about the usual way he's seen this issue worked around, creating a separate mocked class instead of using the actual tool. Fortunately, if you're a Guzzle user, there's a tool that comes with the HTTP client that can be used in your unit tests in much the same way as a normal Guzzle instance: the Guzzle MockHandler. He includes some example code showing how to use this class and inject it into your client and use it in much the same way as a normal client instance.

Sergey Zhuk has posted the second part of his "fast web scraping" series that makes use of the ReactPHP package to perform the requests. In part one he laid some of the groundwork for the scraper and made a few requests. In this second part he improves on this basic script and how to throttle the requests so as to not overload the end server.

t is very convenient to have a single HTTP client which can be used to send as many HTTP requests as you want concurrently. But at the same time, a bad scraper which performs hundreds of concurrent requests per second can impact the performance of the site being scraped. Since the scrapers don’t drive any human traffic on the site and just affect the performance, some sites don’t like them and try to block their access. The easiest way to prevent being blocked is to crawl nicely with auto throttling the scraping speed (limiting the number of concurrent requests). The faster you scrap, the worse it is for everybody. The scraper should look like a human and perform requests accordingly. A good solution for throttling requests is a simple queue.

He shows how to integrate the clue/mq-react package into the current scraper to interface with a RabbitMQ instance and handle the reading of and writing to the queue. He includes the code needed to update the ReactPHP client. The mq-react package makes the update simple with the HTTP client reading from the queue instance rather than the array of URLs. One the queue is integrated, he then shows how to create a "parser" that can read in the HTML and extract only the wanted data using the DomCrawler component.

Sergey Zhuk has a post on his site that covers using a Router with a ReactPHP component. This router lets you more easily direct the HTTP requests coming into the application to the correct piece of functionality.

Router defines the way your application responds to a client request to a specific endpoint which is defined by URI (or path) and a specific HTTP request method (GET, POST, etc.). With ReactPHP Http component we can create an asynchronous web server. But out of the box the component doesn’t provide any routing, so you should use third-party libraries in case you want to create a web-server with a routing system.

He starts with an example of manual routing, showing the code for a basic server and adding in handlers based on the path+HTTP verb to respond with different content. He expands this basic example out to a more "real world" situation of the usual CRUD handling for "tasks". The post then shows how to change things up and use the FastRoute routing package to remove the manual route definitions from the server and define them in the router instead. It can then dispatch these to the correct location more easily. The post finishes up showing an additional feature: how to use wildcards in these URL definitions.

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.

On the Laravel News site today there's a tutorial posted showing you how to test your middleware with HTTP tests and how they can help in more practical testing of your application.

In this post, I’d like to demonstrate a practical example of testing a middleware using HTTP tests. Testing at the HTTP level can make your tests more resilient to change and more readable.

On a recent episode of Full Stack Radio (#72) with Adam Wathan and Taylor Otwell, it was refreshing to hear them find a lot of practical value in HTTP testing. I have found HTTP tests to be easier to write and maintain, but did feel like I was Doing Testing Wrong™ somehow or that I was cheating by not mocking and isolating everything. If you haven’t listened to this episode yet, give it a listen, it’s full of good, practical testing advice.

He starts by laying out the example middleware he wanted to test, one for validating and securing webhooks coming back from the Mailgun service to handle incoming email. The code for the middleware is included, defining the handle, buildSignature and verify methods. He then uses the artisan command to make a test and provides the code to test and ensure that the middleware forbids requests that aren't POST.

On his Medium blog Peter Lafferty has written up a post showing you a method for HTTP request validation in Silex, the microframework from the creators of Symfony.

This article covers three validation scenarios: routes, query strings [and] POST with a JSON body.

He starts with a simple Silex application that creates a "RESTful" API with endpoints providing emojis back when queried (three endpoints). He then uses this to show how to validate:

• routes for their expected values in the URL
• using a ValidatorService provider to build a set of assertions (GET request)
• using the same service to create assertions for the JSON content of a POST request

All code required is included in the post including the correct handling of the emoji output via a UTF-8 JSON response handler.

On the Zend Framework blog today Matthew Weier O'Phinney has written up a post showing how to implement specialized responses in Diactoros, a PHP package that makes it easier to work more directly with the request and response in your application.

When writing PSR-7 middleware, at some point you'll need to return a response.

Maybe you'll be returning an empty response, indicating something along the lines of successful deletion of a resource. Maybe you need to return some HTML, or JSON, or just plain text. Maybe you need to indicate a redirect.

But here's the problem: a generic response typically has a very generic constructor. [...] Fortunately, Diactoros provides a number of convenience implementations to help simplify the most common use cases.

He then spends the rest of the article showing some example responses types and the code to make them work:

• EmptyResponse
• RedirectResponse
• TextResponse
• HtmlResponse
• JsonResponse

Each one is included as a part of the Diactoros package. For more information, check out the documentation for the package and accompanying examples.

On the Laravel News site they've posted a tutorial showing you how to create custom Artisan commands making them available right along with the built-in framework commands.

I’ve written console commands in many different languages, including Node.js, Golang, PHP, and straight up bash. In my experience, the Symfony console component is one of the best-built console libraries in existence—in any language.

Laravel’s artisan command line interface (CLI) extends Symfony’s Console component, with some added conveniences and shortcuts. Follow along if you want to learn how to create some kick-butt custom commands for your Laravel applications.

The tutorial starts off with an overview of the current command structure and how a basic Symfony Console command is structured (code). They then get into the creation of their custom command - a "health check" command - by creating a new Laravel project and using the "make:command" command to build out the skeleton code for you. They add the command into the current config and show output of how it should now show in the "help" listing. From there the tutorial shows how to implement the HTTP checking with Goutte and how ot run it on a schedule, writing the result of the check to a log.

On the Laravel News site they've introduced a package from Adam Wathan that cam help simplify the use of the popular Guzzle package for making HTTP requests. Zhttp is a wrapper around Guzzle and tries to make the code to make the requests simpler and easier to follow.

Zttp is a new PHP package by Adam Wathan that is a Guzzle wrapper designed to bring an expressive syntax and simplify common use cases. [...] Zttp simplifies the code to make the request and automatically returns the JSON response.

A few other examples of requests using the tool are provided: POSTing with parameters, sending a PATCH/PUT request, adding an Accept header and how to prevent the request from following redirects. You can find out more on the project's GitHub repository and grab the latest release to try out in your own code.