In a new post to his site Rob Allen shows you how he adapted a package of his own to work with a Slim framework based API to render "ApiProblem" types correctly (according to this specification).

In the API I'm currently building, I'm rendering errors using RFC 7807: Problem Details for HTTP APIs. As this is a Slim Framework project, it uses PSR-7, so I updated rka-content-type-renderer to support problem.

RFC 7807 defines a standard for sending details of an error in an HTTP response message. It supports both XML and JSON formats.

He starts with an example of the "Problem" response format that includes data for the type of error, details and links to other related objects. He points out this package from Larry Garfield that handles the actual output of the respose format but Rob needed a way to shift between JSON and XML formats too. This is where his updates to his package came in, changing it to include a ApiProblemRenderer that reads the "Accept" header of the incoming request and correctly formats the results accordingly.

Rob Allen has a quick post to his site talking about some of the improved error handling that's been updated in the latest version of the Slim microframework to help make reporting issues easier in multiple contexts.

From RC1 of Slim 3, we have improved our error handling. We've always had error handling for HTML so that when an exception occurs, you get a nice error page [...] However, if you're writing an API that sends and expects JSON, then it still sends back HTML. [...] At least we set the right Content-Type and status code! However, this isn't really good enough. We should send back JSON if the client has asked for JSON. Until RC1, the only way to do this was to register your own error handler.

With Slim 3 the framework handles things more correctly based on the value of the "Accept" header sent along with the request. This value is checked and, if it references JSON or XML, the error message is translated either giving the default output or reporting back for the "notFound" and "notAllowed" error types.

On the Qandidate.com blog today there's a new tutorial talking about the use of the Accept header in REST HTTP requests and, more specifically, working with it in a Symfony-based application.

I investigated different ways to version a REST API. Most of the sources I found, pretty much all said the same thing. To version any resource on the internet, you should not change the URL. The web isn't versioned, and changing the URL would tell a client there is more than 1 resource. [...] Another thing, and probably even more important, you should always try to make sure your changes are backwards compatible. That would mean there is a lot of thinking involved before the actual API is built, but it can also save you from a big, very big headache. [...] Of course there are always occasions where BC breaks are essential in order to move forward. In this case versioning becomes important. The method that I found, which appears to be the most logical, is by requesting a specific API version using the Accept header.

He shows how to create a "match request" method in his custom Router that makes use of the AcceptHeader handling to grab the header data and parse it down into the type and API version requested. He also includes an example of doing something similar in the Symfony configuration file but hard-coding the condition for the API version by endpoint.

In this new post to his site Bob Majdak talks about extending iterators to help make it easier to customize it for your needs.

One of the nice things about iterators is the ability to shove them into other iterators, allowing you to wrap their functionality in other functionality to return a more precise result set. Take for example the idea that we want to read a directory to list only the images inside of it. There are two main ways to do this, via readdir functions and via FilesystemIterator objects. Going the FilesystemIterator route, one common way seems to be extend another class called FilterIterator which allows you to customize a filter based on you overwriting a method called accept().

He shows not only overriding the "accept" method, but also the constructor to make using this new iterator a much simpler (and cleaner) call. You can find out more about the FilesystemIterator (and others) over in the Iterators section of the PHP manual.

Jason Fox has a recent post to his site about using "Accept" headers in Zend Framework 2 apps to set the format of the return data from a request.

In this article I detail the process by which you can set up your controller actions in Zend Framework 2 to return either the default HTML, or JSON data depending on the “Accept Header” in the request. It incorporates changes related to a security update added since this very helpful article was written, and expands on some of the intricacies of making your web layer objects better “json providers.”

His example uses a "ViewJsonStrategy" and the criteria to look for to determine which version to respond with (HTML or JSON) - the Accept header. It uses the JSON encoder/decoder instead of the built-in PHP one to he could use the included "toJson" method to customize the output of the JSON instead of just returning everything.

Cal Evans has posted the first part of his look at DTAP - development, testing, acceptance and production - and how it applies to PHP development.

There are four primary systems that need to be set up and isolated. And they are described by the acronym DTAP—Development, Testing, Acceptance, and Production. One thing that has changed recently, though, is that these systems no longer have to mean separate hardware.

He gives an overview of each, setting out definitions to be used for the rest of the series with the next part discussing some of the "smaller moving pieces" of the process.