PHPMaster.com has posted the latest tutorial in their series covering RESTful APIS - part four of "REST - Can you do More than Spell it?" In this latest part of the series, they focus on something very key to RESTful services, the HTTP spec (and headers).

We're getting close to the end now, and the only thing remaining is to discuss a little more about the protocol you'll most likely use in any RESTful application that you write. Because HTTP is so often used with REST, that's the protocol I'd like to focus on.

He goes through the structure of a typical (raw) HTTP header and talks about some of the more common headers and what actions/settings they represent. He includes examples of setting headers (with header, naturally) and a curl example showing how to set the request headers. The tutorial is finished off with a brief mention of custom HTTP headers and the the good and bad that comes with them.

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.

On PHPMaster.com today there's a new tutorial from Alejandro Gervasio about using virtual proxies in your application - a method in development that provides a layer of abstraction on top of domain objects and makes it more efficient to work with (and lazy load) them.

Often referenced by a few other fancy names, the substitute is generically called a virtual proxy, a sort of stand-in that exploits the neatness of Polymorphism and interacts with the actual domain objects. Proxies aren't new to PHP. Doctrine and Zend Framework 2.x make use of them, although with different aims. On behalf of a didactic cause, however, it would be pretty instructive to implement some custom proxy classes and use them for lazy-loading a few basic aggregates from the database, this way illustrating how virtual proxies do their stuff under the hood.

He starts off by setting up a domain model for a "Post" and "Author" - a typical blog example.Based on the definition of these classes, he creates a mapper class to generate Author objects and an "AuthorProxy" class that uses a "loadAuthor" method to only load in the author's details when a property is requested. He gives a bit more code showing it in action and the difference between using the normal Author and AuthorProxy class.

While not specific to PHP, security is something that all developers need to think about in their applications. To that end, the Infosec Institute has published this guide to helping you prevent SQL injection attacks that could come in via the HTTP headers of requests to your site.

During vulnerability assessment or penetration testing, identifying the input vectors of the target application is a primordial step. Sometimes, when dealing with Web application testing, verification routines related to SQL injection flaws discovery are restricted to the GET and POST variables as the unique inputs vectors ever. What about other HTTP header parameters? Aren't they potential input vectors for SQL injection attacks? How can one test all these HTTP parameters and which vulnerability scanners to use in order to avoid leaving vulnerabilities undiscovered in parts of the application?

They start by describing the different kinds of headers that the attacks could come in on - GET, POST, cookies and the other HTTP headers. According to some results, the HTTP headers option is the least protected in most common applications. He includes some good examples of headers that might contain malicious data such as:

• X-Forwarded-For
• User-agent
• Referer

Techniques are also included showing you tools and methods to help test your own applications including some in-browser tools and external applications (like Sqlmap, Nessus, WebInspect, SkipFish and Wapiti) with some average scores from running them on various coverage scores.

Lorna Mitchell has a new post to her blog today showing how to use the functionality provided by the pecl_http extension to make an OAuth2 connection to Google.

I've written about Google and OAuth before, but that was OAuth v1.0, and they are introducing OAuth2 for their newer APIs; in this example I was identifying myself in order to use the Google Plus API. [...] OAuth 2 doesn't need an extension or any particular library as it doesn't have the signing component that OAuth 1 had, and OAuth 2 also has fewer round trips. It does require SSL however, because the requests are in the clear.

She includes some code snippets with an example of a connection - making a request to the remote HTTPS resource, adding some parameters to the URL (including the response type, your client ID and a redirect url). The response then contains the "code" value you'll need to make the second request to fetch the access token you'll need on future requests. You can find out more about the interface she's accessing in these docs about the Google Plus API.

In this recent post to her blog, Lorna Mitchell shows how to use the Jira REST API (provided as a part of some of the newer versions of the tool) to create a "dashboard" of the latest items added to the tracker.

Today what you get is an example of integrating with JIRA's REST API, because their recent "upgrade" locked me out of the issue listings pages completely and I really do need to be able to see a list of bugs! Their bug editing screen is quite usable, so it's just the list that I need here, but you could easily call their other API methods as you need to. These examples are PHP and use the Joind.in Jira tracker), parsing the JSON results and displaying the results as a simple list, looping with a foreach and outputting some HTML.

On PHPMaster.com there's a recent tutorial introducing the concept of a "domain model" and showing how to create them in PHP (manually, not inside of any ORM or database solution).

First off, creating a rich Domain Model, where multiple domain objects with well-defined constraints and rules interact, can be a daunting task. Second, not only is it necessary to define from top to bottom the model itself, but it's also necessary to implement from scratch or reuse a mapping layer in order to move data back and forward between the persistence layer and the model in question.

They include an example of a set of domain models tat relate to one another - a blog setup with posts, comments and users. They show how to create the AbstractEntity to handle a bit of the magic behind the scenes, an example "Post" and "Comment" models and how they can be put to work creating some posts and appending comments. A little bit of markup is included to output the results.

Mike Wallner has shared a quick and easy HTTP caching technique in a new post to his blog today. The key is in using the PEAR HTTP_Header package.

Ever watched youself browsing e.g. a web forum? Noticed that you viewed the same page several times? Well, this means extraordinary and useless load for your server if there's no caching mechanism implemented in the web application. Even if there is some file or db cache you can still improve performance with implementing some http cache.

With a few simple lines of code using HTTP_Header, you can tell your scripts how long to set the "expires" header to on your requests. This increment (in seconds) is relayed to the browser to tell it when to next fetch the page and not reload from cache.

Lorna Mitchell is back with a second installment in her "Building a RESTful PHP Server" series with this new post about handling and routing the incoming requests. (You can find the first part about working with the request here)

This is the second part of a series, showing how you might write a RESTful API using PHP. This part covers the routing, autoloading, and controller code for the service, and follows on from the first installment which showed how to parse the incoming request to get all the information you need.

She shows how to grab the controller name from the incoming request (based on her previous code), create the object for it and execute the requested action name. Also included is a sample autoloader and a basic controller - a UsersController with "getAction" and "postAction" methods for responding to GET and POST requests.

In a recent post to his blog Chris Hartjes looks at the idea of better HTTP Request/Response functionality in PHP, more than just the superglobal handling and PECL HTTP extension it has now.

I think the fact that we have $_POST and $_GET lulls some of us into the false sense that we should have $_PUT and $_DELETE objects, since that would map to the commonly-desired set of HTTP verbs that REST likes to use. But what should be inside those things, or should we be moving towards a more Pythonesque solution where a Request object, as part of core or via a only-really-for-the-brave- PECL extension?

He mentions opinions from other PHP community members (Laura Thompson and Elizabeth Smith) and a bit about what he (and I'm sure other developers) are looking for in a more full-featured request/response handling feature.