Alejandro Celaya has posted a new tutorial to his site covering the handling of PUT requests in PSR-7 applications for file uploads via middleware.

It has been a long time since I first realized that handling file uploads in non-POST requests (like PUT) wasn't an easy task. One could assume the $_FILES array should be populated regardless the HTTP verb, but actually, PHP doesn't do it on its own.

After a long time wanting to find a solution to this problem, I've finally dedicated the time to get something functional, that allows file uploads to be transparently handled regardless the HTTP verb (it works the same way in POST, PUT and PATCH requests).

Since nowadays I try to work with psr-7/middleware based applications, I have created a Zend Expressive app that registers a middleware capable of parsing a multipart/form-data request body, populating the request's uploaded files array and parsed body array. This way, you can call $request->getUploadedFiles() or $request->getParsedBody() in any PUT or PATCH action, the same way you would do in a POST action.

His example application shows a simple HTML form that, when submitted, changes the HTTP request type based on a radio option selected at the bottom. He walks through the steps that the application takes to handle the upload via this middleware that makes it possible to work with the body of the PUT the same way as other requests. He goes through each part of the code that's required to make the middleware flow work and finishes up the post looking at a few other things to consider (like opting for POST over PUT for file uploads).

A discussion has started up on Reddit.com about the request for a "$_PUT" superglobal to match the already existing "$_POST" and "$_GET" (as is mentioned in this bug).

Data that is posted to PHP via the PUT method is not parsed at all and is not available to PHP. This is particularly problematic for data sent encoded as 'multipart/form-data'. [...] This is something that would help every RESTful interface that people are trying to do with PHP. There are many people who have these problems and have to implement (usually incomplete and/or buggy) PHP solutions.

In the Reddit post there's a mixed set of opinions - some say that things work well enough as is (content pulled from the raw stream) and others say that adding something like this makes the HTTP support more complete and functional.

On the PHPMaster.com site there's a recent tutorial posted, the first part in a series of posts from David Shirey about building REST APIs in PHP. This first part of the series stays pretty high-level and really just introduces some common REST concepts.

Thousands of years ago when we first started building web pages, things were very simple. You’d put some text on the page, maybe even an image, and that was pretty much it. But today it’s a whole different ball game. Instead of static pages there’s the dynamic applications we’ve come to depend on. And so, how these applications are designed to communicate becomes very important. In this series I’ll introduce you to the REST architecture style. In this article I’ll help you to understand exactly what it is, and later I’ll show you how it can be implemented in a PHP environment.

He defines the term "REST" for those not familiar and how a typical RESTful API allows other end users/software to interact directly with its data. He outlines some of the common principles of REST and finishes the post with a comparison of two HTTP verbs - PUT and POST.

Chris Hartjes and Ed Finkler (two well-known PHP community members) have started up a podcast where they talk about, basically, whatever they want in their "piss-and-moan-driven-development" style. In their first episode, they talk about what they hate about PHP.

Listen to a couple old dudes complain that they don’t like PHP anymore. Yes, I know, this sounds pretty compelling.

They specifically mention the PUT method support in PHP. You can download the mp3 (about an hour and a half long) and check out the two hosts on Twitter: Chris and Ed.

On PHPBuilder.com today there's a new tutorial from Jason Gilmore about building a simple RESTful API with Slim, a microframework for PHP.

Although a relatively new entrant in the PHP framework sweepstakes, I've been lately quite intrigued by Slim, a slick RESTful microframework modeled after Ruby's Sinatra, which is coincidentally by far my favorite microframework available for any programming language. In this article I'll show you just how easy it is to get started building a powerful RESTful API using this streamlined framework.

Setup of the framework is as simple as downloading the latest copy from its github repository. It can then be included and used to make the simple routes in his examples. He uses a "games" request type to show how to handle GET, POST and PUT requests through Slim's simple interface.

Lorna Mitchell has added a new post to her blog about adding in PUT variables to your Zend Framework Zend_Request object (useful for web services).

Its very simple: I have extended Zend_Controller_Action with my own, and all controllers inherit from here. This has a routeAction() which grabs the incoming variables from a PUT request and sets them as parameters within the usual $this->getRequest() scope, then forwards on the request.

Her example adds a call to the isPut method to check for the PUT request type and, if found, takes in the request values and pushes them back into the action's parameter values. Then the controller can make a call back to the request object to pull in the parameters when needed.

In a new post to his blog Ian Selby looks at working with REST requests in PHP. He includes some of the basics of REST too, for those not completely familiar with the term.

APIs have become a very commonplace part of many popular web sites and services...especially REST APIs. I’ve already discussed how you can roll your own REST API for your PHP apps, but I’ve also received countless requests to go over how to actually make RESTful requests. That’s exactly what we’ll take a look at in this article

His tool of choice is the curl extension, making it simple to create a class wrapper with methods like executePost, executeGet, setAuth and, of course, execute. He outlines the class and gives the code blocks that fit inside each of the major functions. In the end you'll have a class that can make GET, POST, PUT and DELETE requests and be able to correctly parse the response.

Kris Jordan recently posted five tips to help you get a "more correct" REST interface in your application.

As we entered a programmable web of applications with APIs the decision to ignore HTTP gave us problems we're still dealing with today. We have an internet full of applications with different interfaces (GET /user/1/delete vs. POST /user/delete {id=1}). With REST we can say /user/1 is a resource and use the HTTP DELETE verb to delete it.

Here's the five (six?) tips:

• Using PUT and DELETE methods
• Send Custom HTTP/1.1 Headers
• Send Meaningful HTTP Headers
• Don't Use $_SESSION
• Test with cURL or rest-client
• Use a RESTful PHP Framework

In this new post to the symfony blog today Fabien talks about some of the "small things" that help to make this latest version of the framework (1.2) even better.

As for every symfony version, we try to simplify the API and make it more intuitive and powerful. Here are some examples that you will soon enjoy in symfony 1.2.

There's four included in the post (and many more in the framework):

• Application name in CLI tasks
• Native PUT and DELETE support from the browser
• Shortcuts in the response
• sfValidatorSchemaCompare validator

For a recent REST web service project, Lorna Mitchell had to put together a server for the remote clients to use. She started with a GET request then moved to handling a POST request then to a PUT request - that's where the difficulty came in:

PHP doesn't have a built-in way to do this, and at first I was a little confused as to how I could reach this information. It turns out that this can be read from the incoming stream to PHP, php://input.

Pulling from that stream gave her the raw data she needed (nicely urlencoded too) that she could parse out and use. She includes a simple example that has a check for the REQUEST_TYPE in the _SERVER superglobal to see how the request should be handled (PUT versus GET).