Archive for January, 2009
Sat, 31 Jan 2009 3:42 UTC
When I was contacted by a representative of Packt Publishing to review RESTful PHP Web Services by Samisa Abeysinghe, I was naturally interested. After all, I’ve written and spoken a lot about representational state transfer (REST). But I was also skeptical because plenty of people these days talk about RESTful web services, but they don’t really explain REST.
Abeysinghe approaches the topic from a very practical level. From the very first chapter to the last, RESTful PHP is chock full of code samples and discussion of tools to access and build RESTful services. The problem, though, as Lorna Mitchell points out, is that ”[v]ery few services that claim to be RESTful actually are, which makes writing anything along these lines very tricky.” I agree. I would have liked to have seen a more critical look at the so-called RESTful services profiled in the book, with the author explaining the principles of REST by showing how the services examined are or are not RESTful.
In addition, the book devotes very little space to actually describing the principles of the REST architectural style. Instead, there is only a small section in the first chapter that lists some of the principles of REST in a bullet list. I say “some,” because the book fails to mention the principles of client-server, caching, layering, and code-on-demand. Of particular importance to me are the principles of caching and layering because I think these make for the most compelling arguments for using the REST style. Later, when the book tries to make a case for the need for RESTful web services, it talks only about the need for web services and why PHP programmers need to know how to consume REST services, rather than actually explaining why REST itself is important.
While my criticism of the author’s lack of focus on defining and explaining REST is harsh, I will return again to my point about the practically of the book’s examples. It is filled to the brim with working code examples that show how to consume Flickr, BBC News, Yahoo Maps, and other web services, and he discusses many tools to use as HTTP clients in PHP, from curl to Zend_Rest_Client. He also goes into much detail explaining how to design and implement RESTful web services, using a fictional library service as an example. In truth, the real focus on the book isn’t on REST but on the resource-oriented architecture, and to that end, he does offer some good discussion, even covering such topics important to the community as PUT vs. POST and URL design, nuances of design that REST does not cover. And, at the end of the day, what is really more important to a programmer who needs to quickly consume web services for a project: pragmatism or theoretical discussion? My bet is on pragmatism, and this book offers plenty of it.
So, if you’re looking for a full-fledged definition of representational state transfer, this book is not for you. Read Roy Fielding’s dissertation, if you want that. However, if what you’re looking for is a practical approach to consuming resource-oriented web services, then RESTful PHP Web Services is what you’re looking for.
3 Comments »
Permalink
Tags: books, php, rest
Wed, 28 Jan 2009 4:27 UTC
The last post in my HTTP status code series was just over six months ago. I’m sorry for taking so long to revive the series, but I’m back with a discussion about the 4xx status codes. I hope you enjoy it!
The 4xx series of HTTP status codes is intended for client errors. That is, the server determines that there is an error occurring as a result of bad or missing data in the request from the client. The 404 Not Found status code is the most recognizable of these, and it’s the server’s way of telling the client that the requested URI is not available on the server. This is not the server’s fault, but, rather, it is the client’s, so the server responds saying, “Sorry, pal! I can’t find what you’re looking for.”
In an earlier post, I mentioned the 100 Continue status code. I mention it again here because the use of an Expect: 100-continue request header in a “look-before-you-leap” (LBYL) request can be useful to let you know of potential problems with your request before you receive any of these status code responses from the server.
Let’s use the same request from the 100 Continue post as an example:
POST /content/videos HTTP/1.1
Host: media.example.org
Content-Type: video/mp4
Content-Length: 105910000
Authorization: Basic bWFkZTp5b3VfbG9vaw==
...
Note that this request does not contain the Expect header, and it is assumed that the body of this request contains the full binary content of the video being posted.
For the sake of example, let’s assume that the server doesn’t allow POST requests to the /content/videos URI. If this is the case, then the server should return a 405 Method Not Allowed status code in response to this request. This is a condition that we could have checked for with the LBYL request prior to sending the full 105,910,000 bytes of the video, thus saving bandwidth, client resources, and server resources.
HTTP/1.1 405 Method Not Allowed
Date: Wed, 28 Jan 2009 03:04:25 GMT
Allow: GET,HEAD
In addition, to the 405 Method Not Allowed status, according to RFC 2616, the server must included an Allow header listing the valid methods for the requested resource. Sending the Allow header in response to HEAD requests (and all requests for that matter) can also help inform clients of acceptable methods.
If the server does allow POST requests at this URI but we fail to send the Authorization header with the request, then the server should respond with a 401 Unauthorized status, telling the client to resend the request with proper authorization. The server must include a WWW-Authenticate header in this response to indicate the expected authorization scheme. If the request, however, does include the Authorization header, as illustrated in the example, but the authentication fails for whatever reason, then the server should respond with a 403 Forbidden status and a description with the reason for the failure in the response body.
If the request doesn’t include the Content-Length header, then you might want the server to respond with a 411 Length Required status. Requiring the length and comparing it to the length of the actual request body is a good way to determine whether there was any loss of data. However, if the integrity of data is a concern, you might want to require clients to include the Content-MD5 header in the request. Since there is no status code to indicate Content-MD5 as a requirement, simply return a 400 Bad Request status stating your requirement of the Content-MD5 header in the response body.
The 400 Bad Request status code literally means that the “request could not be understood by the server due to malformed syntax,” but it is a generic enough response that it can be used for a variety of other client errors not covered by the other 4xx series status codes. For example, I have used 400 Bad Request as a way to indicate data validation failures in POST and PUT requests.
If the full request reaches the server, but the server determines that the 105,910,000 bytes of the video is beyond the acceptable limit—maybe we want to limit users to 50MB uploads—then respond with 413 Request Entity Too Large because the request body is larger than the server is willing to process. Again, the client could avoid this by using a LBYL request.
Likewise, if the server doesn’t want to support the video/mp4 media type, then it should respond with a 415 Unsupported Media Type status code. A LBYL request would have told us this, as well.
I’ve already discussed 416 Requested Range Not Satisfiable in a post about range requests and 417 Expectation Failed in a post about the 100 Continue status code.
Finally, we are all familiar with the 404 Not Found status code. I mentioned it earlier in this post. The 404 Not Found status, however, doesn’t tell the client whether the condition is temporary or permanent. It’s a pretty generic “I can’t find it” message. If you know that the resource is gone permanently, you may want to return a 410 Gone status code, instead, as a way of letting smart clients (like search engines) know that they should remove all links to the resource. If the resource has moved permanently, though, I recommend using a 301 Moved Permanently status, which will also tell these smart clients to update their links. How you choose to inform clients of the fate of your resources is up to you, but it’s in your best interest to tell them whether the data has moved or is gone and is no longer available.
I also mentioned the 404 Not Found and 410 Gone statuses when discussing the 201 Created and 202 Accepted status codes.
1 Comment »
Permalink
Tags: http, rest, rfc2616, standards
Sun, 25 Jan 2009 2:42 UTC
We’re well into the New Year—24 days to be exact—and I’ve long since been putting off this post, but it’s not really a single post. Instead, it’s a collection of things that I’ve been wanting to say but have been putting off, and it’s a look forward to things I’m working on, would like to see happen, or would like to be involved with this year. So, rather than the obligatory look back at what I did last year, this is a look forward at what I’m interested in for the coming year (in no particular order).
First of all, I would like to offer some congratulations to a handful of friends of mine. These congrats have been a long time coming from me and are already old news to many of you. In no particular order, I want to congratulate: Andrei Zmievski on being hired as an Open Source Fellow at Digg; Jon Tan on taking a role as the new Creative Director at OmniTI; Cal Evans, who moved to the Netherlands to be the Director of the PHP Centre of Expertise at Ibuildings; Marco Tabini and Keith Casey for launching Blue Parabola, and Matthew Turland for joining them; Eli White for accepting a position at Zend as the Zend Community Manager/Leader & DevZone Editor-In-Chief; and last, but not least, Brian DeShong for his promotion to Director of Technology at Schematic.
Next, I wanted to take a moment to mention and promote the writing I’ve been working on. I didn’t publish a single thing last year, and in 2007, I published only one article, so I resolved this year to get off my ass and remedy this. In February, php|architect will publish my article entitled “Grokking the REST Architectural Style.” This article attempts to explain what Representational State Transfer really is by going beyond peoples’ fascination with designing URLs, using XML, and focusing on HTTP methods. Instead, I’ll look at the real heart of REST with hopes that readers will fully understand what it means to build a RESTful application. A fellow web services aficionado said of the article, “I think you expressed very nicely what the concepts are all about—and without a URL or HTTP verb in sight!”
Following the REST article, in March php|architect will begin publishing my monthly column “From the Cloud.” In “From the Cloud,” I’ll be looking at practical web services you can use, as well as exploring trends that are transforming the way we use the Web. Here’s a quick blurb from the column that describes its focus:
As the Web matures and enters its third decade of life, many services are turning to cloud-based models of data storage. End users are becoming more and more comfortable with the notion that their data lives in the ether of the Internet rather than on their personal computers. Finding that data, retrieving it, manipulating it, and using it in meaningful ways are the challenges that face the era of the intelligent Web. I hope you’ll join me each month as we explore these services and technologies From the Cloud.
Finally, later this year, php|architect will publish another article I’m working on that will take a practical look at using HTTP in your applications in a RESTful way. There may also be a book idea or two in the works for me, but more on that later.
Oh, and I also had the privilege of being invited again to write a PHP Advent post during the month of December. I wrote a post entitled “Practice Safe & Idempotent Methods.”
Furthering my ramblings in this post, I also wanted to mention some community projects I’m working on this year. As always, I’d like to see PHPCommunity.org evolve and grow into a real website that offers real value to the PHP community, so that’s on my list of things to do. I’ll post more on that in the future. In addition, I have some plans for Atlanta PHP this year that include a new website, incorporation so we can accept donations, and an event to occur later in the year, but you’ll hear more from me about this as the details are finalized. Inspired by my own writings for the “From the Cloud” column, I’ll also be developing a PHP library of classes for interacting with various web services. This began with the Amazon Web Services library in PHP project, but I’ll be migrating that elsewhere to be part of a larger project in the near future, so be on the lookout for that.
Last, but not least, I wanted to mention the website that I built for my dad over the holidays. He recently launched his own business, Small Business Resource Associates, that provides services to small businesses and commercial real estate investors. I did all of the HTML/CSS and PHP programming for the website, while my aunt did the design work. It was an interesting project for me because I haven’t really touched front-end (client-side) web development in several years (I stick mainly to back-end, server-side development these days), and I was proud that I was able to make a website that validates successfully as XHTML 1.1. Another interesting part of the site is that it has a blog, something that I don’t believe many in the financial services industry are doing, so I think that’s one thing that sets apart Small Business Resource Associates from the competition. If your small business is looking for a loan, business plan, business consulting, SBA help, etc., please check it out.
Well, that’s a wrap. I’ve got a growing list of topics I want to blog about, so I hope that you’ll be hearing much more from me this year than you did last year.
Happy New Year!
1 Comment »
Permalink
Tags: atlantaphp, http, php, phpc, phpcommunity, rest, webservices
Wed, 7 Jan 2009 16:35 UTC
Someone at the office sent around a link to an InfoWorld article that discusses a blog post made by Anne Thomas Manes, vice president and research director at Burton Group, in which she announces the death of SOA.
I thought my response was worthy to share on my blog, so here it is:
It’s an interesting argument she makes in the obit. She’s saying that the term “SOA” has become confusing and, thus, misleading. All it is anymore is marketing-speak, just like “Web 2.0.” Everyone and their brother has a different idea of what Web 2.0 means, and I suspect the same has happened for SOA. However, she says that “although the word ‘SOA’ is dead, the requirement for service-oriented architecture is stronger than ever.”
She goes on to say that “successful SOA (i.e., application re-architecture) requires disruption to the status quo. SOA is not simply a matter of deploying new technology and building service interfaces to existing applications; it requires redesign of the application portfolio. And it requires a massive shift in the way IT operates.”
What is required is good software architecture, not simply throwing on layers and layers of other services and hoping for the best.
I think this is her own attempt to disrupt the status quo. She wants to do away with the terminology because it has clouded the real issue. What’s the real issue? She highlights this when she concludes: “and that’s where we need to concentrate from this point forward: Services.”
IMO, bolting on services should never become a replacement for good software architecture, and I think that’s what has happened in many cases with SOA. Instead, we need to really think about and design how services fit into an “application portfolio.”
No Comments
Permalink
Tags: soa, software-architecture, webservices
Sat, 3 Jan 2009 5:12 UTC
Started by Tony Bibbs (or maybe Marcus Whitney before him) and tagged by Elizabeth Naramore and Jon Whitcraft, I have succumbed to the 2009 blogging phenomenon known as “tagging.” Initially, I was going to ignore the tag, but when Elizabeth tagged me “just because,” I knew it was on.
So, here I am, writing the seven facts about myself. Happy, Elizabeth ?
- I was a youth minister for just over 4 years; I quit because I was burned out and tired of parents telling me what to teach their children; I have now become jaded and cynical of organized religion… maybe I’ll get better some day.
- I didn’t drink any alcohol until I was 21 (honest).
- I was in a short-lived, lounge-rock band in college called Not Quite Seven; we played mostly at Uncle Calvin’s in Carrollton, GA; our last show was at GA Tech in 2000—I played bass and sucked.
- My degree is in English Literature, not Computer Science.
- I go by my middle name, so consider “Ben Ramsey” a pseudonym of sorts and not my legal name.
- I taught myself to play guitar and hammered dulcimer, though I am long out of practice for both.
- My first program was written in BASIC on an Atari 400, and it was a Mad Lib generator that prompted the user for input (nouns, adjectives, adverbs, etc.) and plugged these variables into a story it printed out; I was 8 or 9 years old.
And now I get to tag people! Yay! Here are my tagees:
And here are the rules:
- Link your original tagger(s), and list these rules on your blog.
- Share seven facts about yourself in the post—some random, some weird.
- Tag seven people at the end of your post by leaving their names and the links to their blogs.
- Let them know they’ve been tagged by leaving a comment on their blogs and/or Twitter.
No Comments
Permalink
Tags: meme, php
