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.

In a new post to his site Alejandro Celaya shows you how to dispatch REST-like requests in Zend Expressive using a single-controller method.

I was digging into Zend Expressive and how to use controllers that allow me to share dependencies between different routes, instead of having to use different middlewares every time. Abdul wrote a great article on this subject that you can find here, which also became part of Expressive's cookbook some time later.

This is a perfect approach that easily allows to reuse some code, but then I thought how to do something similar in a rest environment, having a single class with different dispatchable methods that will be called depending on the request's HTTP method. This is a possible solution based on ZF2's AbstractRestfulController.

He starts by creating an AbstractRestController class to handle the basics of the REST handling, essentially matching verbs to their actions. He then extends this with a RestUserController class that overrides the necessary methods for only the HTTP verbs you want to change. He then shows how to register the route so it can be used by any request verb type (GET, POST, PUT, etc).

Mathias Verraes has an interesting post to his site suggesting that using verbs in class names can make for easier to understand and easier to read code - more "natural language."

When you first learned Object Oriented Programming, somebody probably told you that objects map to things. And that still holds true most of the time. And maybe somebody explained it using the simple heuristic to “look for the nouns”, which can indeed be a great discovery technique. But then somebody probably phrased that as “class names should not have verbs in them”. To me, that rule is severely limiting the possibilities for your models. So here are some cases where I prefer to use verbs.

He suggests that class names, in some cases, could be used as "messages" to the developers using them in the OOP. He includes some suggestions (based on the suggestion of nouns from another post) that use verb-names to convey what they're doing. He also talks about three specific cases - specifications, exceptions and interfaces - and includes samples of each using this idea of verb-based class names.

On NetTuts.com there's a new tutorial about what they think is the one thing every web developer should understand - the HTTP protocol and how its used in web-based communications.

HTTP stands for Hypertext Transfer Protocol. It’s a stateless, application-layer protocol for communicating between distributed systems, and is the foundation of the modern web. As a web developer, we all must have a strong understanding of this protocol. Let’s review this powerful protocol through the lens of a web developer. We’ll tackle the topic in two parts. In this first entry, we’ll cover the basics and outline the various request and response headers.

They cover some of the basics of the protocol first including its statelessness, the concept of URLs and the HTTP "verbs" (like GET, POST and DELETE). They also briefly cover the HTTP response codes (ex. 200, 304) and the flow of the request and response to and from the web server. They also look at some of the basic HTTP headers and the actual low-level text formats of the requests/responses.

There's a section at the end of the post that links you to a few tools that you can use to view the HTTP messaging happening in your requests, some of which you might already have. They also briefly cover the use of HTTP in a few libraries - ExpressJS, Ruby on Rails and jQuery's Ajax handling.

Continuing on with his webcast series looking at using the Slim microframework to create a RESTful web service with JSON Output, John Lebensold takes the code from the previous tutorials (part one, two, three) and adds handling for DELETE to remove values from the data.

This tutorial will show you how to add jQuery RESTful calls for using the DELETE verb when deleting items via a JSON REST interface.

You'll definitely need to check out either the previous tutorials in the series to follow along with the code or grab the current source to see how everything's structured.

In a recent post to his blog Giorgio Sironi takes a look at HTTP "verbs" and their handling in PHP, both on the incoming and outgoing sides.

While PHP is capable of performing HTTP requests towards external servers with any method, either via the HTTP extension or by opening streams directly, the support of the various GET, POST, PUT and other verbs on the receiving side of HTTP requests is a bit more complicated.

He notes that the "more interesting" ones are defined in the HTTP 1.1 spec and, unfortunately, those are ones not natively supported by PHP (like POST and GET are). He recommends a workaround for the problem so you can still work with data that clients PUT or DELETE - using a fopen call to the "php://input" stream on the connection and pulling in the raw data. Not idea, but definitely functional.

In a new post to his blog Keith Casey shares a few tips on naming conventions that can help increase readability in your code and make maintenance simpler in the future.

In my regular web wanderings recently, I found a great post entitled "The 7 Worst Verbs Programmers Use In Function Calls" and couldn't help but be reminded of a system that I worked on a few years ago. The core function of the system was named - no kidding - "doStuff". Everything in the application led towards that, used it, and then did other things as a result.

He suggests a structure he uses - "verbAjectiveNounStructure". Starting with an action, moving to a description of the action, to the target of the action and finally an optional structure - how the returned data is formatted.