Tue, 16 Sep 2008 23:25 UTC
See below for the slides from my Distribution and Publication With Atom Web Services talk given at the 2008 Zend PHP Conference and Expo in Santa Clara, CA.
As we move toward “Web 3.0,” the Web is slowly transforming into a platform upon which massively distributed applications run. Rich clients turn personal computers into thin clients, not storing or processing any data locally but, rather, connecting to a web service where the data resides. These services may target intranets, extranets, or the global Web community, but to work they need a common language. One such language is the Atom Publishing Protocol.
Since its inception as a draft recommendation in 2003, the Atom Syndication Format (RFC 4287) has been used as an alternative to Really Simple Syndication (RSS) feeds on blogs throughout the blogosphere. Most have understood Atom as just another feed format, but the publication of the Atom Publishing Protocol (RFC 5023) opens the door for far more uses of the Atom format as both a means for distribution of data, as well as publication.
Ben Ramsey will introduce the Atom Syndication Format and Atom Publishing Protocol, explaining in depth how these can form the foundation of any web service for publication and distribution of data in any environment, from the enterprise right down to the small business level. Ramsey will also discuss RESTful design principles as they relate to the Atom Publishing Protocol.
2 Comments »
Permalink
Tags: atom, atompub, http, php, presentations, rest, talks, zendcon, zendcon08
Wed, 4 Jun 2008 16:32 UTC
As promised to the attendees of my talks, I have posted the slides for my presentations on SlideShare.
Distribution and Publication With Atom Web Services
The Web is transforming into a platform for distributed applications. Rich clients connect to web services to retrieve and store data. The Atom Publishing Protocol provides a common language for these services. Ben Ramsey introduces AtomPub, explaining how it can form the foundation of any web service for publication and distribution of data for enterprises down to small businesses.
Give Your Site a Boost With Memcache
Today’s high-traffic websites must implement performance-boosting measures that reduce data processing and reduce load on the database, while increasing the speed of content delivery. One such method is the use of a cache to temporarily store whole pages, database recordsets, large objects, and sessions. While many caching mechanisms exist, memcached provides one of the fastest and easiest-to-use caching servers. This talk will cover memcached and the memcache extension for PHP from setting up a memcached server to using it to provide a variety of caching solutions, including the use of memcached as a session data store.
2 Comments »
Permalink
Tags: atom, atompub, dcphp, memcache, memcached, php, presentation, rest, roa, talk
Wed, 27 Feb 2008 18:51 UTC
Creating a RESTful Web service is not simply about serving read-only content through HTTP GET requests. It’s about using the full range of HTTP’s constrained interface to allow clients to consume or create resources within your service. Take a look at CouchDB, for example. Its initial releases look very promising, and the server accepts GET, POST, PUT, and DELETE requests to manipulate resources in the system. I can’t wait until the project implements authentication and authorization features; then, it will look much more attractive for real-world use.
But I digress…
I’ve never been too happy with the Zend Framework’s RPC-based approach to creating RESTful Web services with Zend_Rest_Server, even though I have seen some good discussion about using routes and Zend_Rest_Server to create a resource-oriented architecture. Rather than get too in-depth about this issue, I’ll just point to this thread and save my full thoughts on Zend_Rest_Server for another day.
Suffice it to say, Zend_Rest_Server is not focused on resources but, instead, what you can do with those resources (procedures, methods, verbs) and also assumes you’re only ever going to provide an XML-based, read-only REST service. With REST, this is not the case, and, with the publication of the Atom Publishing Protocol (a protocol that follows the REST architectural style) as RFC 5023, now is the time more than ever to grasp the read-write capabilities of the RESTful Web.
But I digress (again)...
I’ve recently been wrapped up in an effort to design and implement a RESTful API using the Atom Protocol for a project at work. We are using the Zend Framework as the underlying framework for the project, so, in order to follow the Atom Protocol, I needed to support the HTTP methods PUT and DELETE. Apache can handle GET and POST easily because the request itself tells Apache the resource to use when processing the request. With PUT or DELETE, the resource identified by the request may not even exist, so Apache needs you to specify a script to process the request. To do this, I added the following lines to my virtual host configuration:
# PUT and DELETE support
Script PUT /index.php
Script DELETE /index.php
Now, all PUT and DELETE requests are handled by the Zend Framework bootstrap script and the dispatcher handles them in the same way it handles GET and POST requests.
To further support other HTTP methods and the REST architectural style, I’ve proposed the addition of the following methods on the Zend_Controller_Request_Http class:
isGet() – Was the request made by GET?isPut() – Was the request made by PUT?isDelete() – Was the request made by DELETE?isHead() – Was the request made by HEAD?isOptions() – Was the request made by OPTIONS?
getEntityBody() – Return the raw entity body of the request, if present
It’s a very simple addition, but feel free to comment on my patch and offer any improvements or additions.
See also PUT method support in the PHP manual.
14 Comments »
Permalink
Tags: apache, atom, atompub, couchdb, delete, http, php, put, rest, zend, zend-framework, zend_rest_server
Thu, 21 Feb 2008 2:44 UTC
I’ve spent the last month deeply entrenched in the intricacies and idiosyncrasies of RFC 5023 and RFC 4287. You could say that we’re pretty intimate right now… but we haven’t yet made it to “third base.” I’m a gentleman, mind you!
I am, of course, talking about the RFCs for the Atom Publishing Protocol and Atom Syndication Format, and, during my study and research as I’ve been designing and architecting a RESTful API based on AtomPub, I’ve found that, while the AtomPub suggests and describes HTTP status codes to use in return for various behaviors, it does not, in fact, define the format of the response entity. The AtomPub even goes so far as to state in Section 5.5:
Implementers are asked to note that according to the HTTP specification, HTTP 4xx and 5xx response entities SHOULD include a human-readable explanation of the error.
Still, it doesn’t describe the format of that “human-readable explanation.”
This led me to do quite a bit of searching, which turned up some old posts on the atom-syntax mailing list that addressed questions about error responses:
On August 2, 2003, Joe Gregorio wrote in response to someone’s question about error repsponses:
You are right that the specification at this time does not cover error
codes. In general the HTTP Status code should be the first line of
defense, such as 403 Not Authorized, etc. There are errors that will
need more detail than just the status code, and I see three possibilities:
1. Do nothing. That is, let the server decide the error code and
formatting to return it in. For example, when you get a 404 on a
web-site you often get an HTML page or a text/plain document. Not my
favorite option.
2. Mandate a text/plain result that describes the problem.
3. The third option is to define an XML format for describing errors, e.g.
<error>
<title></title>
<description></description>
</error>
A few days later (August 8th), Joe asked the question, “How should errors be handled?” Sam Ruby replied:
Why reinvent?
http://www.w3.org/TR/SOAP/#_Toc478383507
I am often (rightfully) accused of being too obtuse. So let me be
explicit in what I am suggesting here. Design a pure REST API.
Where there seems to be places where "some invention is required",
see if one can reuse precisely those elements - and only those
elements - from SOAP. What you will end up with is a fully REST
compliant interface which will enjoy wide tooling support.
My first reaction was, “Well, why the hell would I want to use SOAP? I’m trying to be RESTful here!” However, I don’t think what Sam meant was to follow SOAP verbatim but to, rather, borrow from SOAP in much the same way that the Atom community borrowed the WSSE username token from the OASIS Web Services Security committee and adapted it from a specification for SOAP services to a more RESTful application by passing the data through HTTP headers.
Essentially, the implication was to adapt a SOAP Fault to work in a RESTful way.
Diverging from the Atom format and adapting a SOAP format to fit my needs didn’t sit well with me, unfortunately. Rather, as I thought more and more about it, I realized that the Atom format itself suited my needs just fine. So, I decided to use an Atom Entry document that would list an atom:category element for every error that occurred while attempting to process the request (i.e. data validation errors, etc.) and send this back to the user with XHTML in the atom:content element that a client could use to parse and present a human-readable message to their users.
Ultimately, I was happy, could “rest” easy, and the end result looked a bit something like this. This example represents a potential XML entity body of a 400 Bad Request response resulting from invalid data submitted to the Atom service through POST or PUT.
<?xml version="1.0" encoding="utf-8"?>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>An error has occurred</title>
<id>tag:example.org,2008-02:1.0/errors</id>
<updated>2008-02-20T17:08:33Z</updated>
<author>
<name>Ben Ramsey</name>
</author>
<category term="9311" label="Title field missing" scheme="https://api.example.org/1.0/categories/errors"/>
<category term="9301" label="Author field missing" scheme="https://api.example.org/1.0/categories/errors"/>
<content type="xhtml">
<div xmlns="http://www.w3.org/1999/xhtml">
<p>Please correct the following errors:</p>
<ul>
<li>
<a href="http://developer.example.org/errors/9311">
Title field missing
</a>
</li>
<li>
<a href="http://developer.example.org/errors/9301">
Author field missing
</a>
</li>
</ul>
</div>
</content>
</entry>
2 Comments »
Permalink
Tags: api, atom, atompub, error, http, rest, rfc4287, rfc5023
