I’ve already invited the Atlanta PHP community, and if you’ll be in the Atlanta area, you should come, too. I can’t say it enough: the price of this conference compared to the value you receive from the talks and networking is a steal! In addition, if you sign up for the tutorials, you get a free training course at php|architect. You really can’t get a better deal at any other conference. I guarantee you’ll be glad you attended.

When: Thursday, November 6, 2008—7pm-9pm
Where: Consulate General of Canada

November Topic: Got a problem? We’ve got answers!

Got a bug that’s been nagging you for hours? How about a feature that you just can’t seem to implement? This month at Atlanta PHP, we’re diverging from our usual presentation format and opening the floor for a “round table” discussion about development problems you are facing.

So, feel free to bring your coding problems to us, and as a group, we’ll come up with the solutions. Bring your laptop or a thumb drive containing snippets/samples of your code or application, so we can look at it as a group. This is sure to be a learning experience for us all.

Our meeting takes place at the Consulate General of Canada at 100 Colony Square in Midtown Atlanta (at the corner of Peachtree and 14th Streets). Click here for directions. You will need to see the concierge in order to gain access to the 17th floor.

PHP Basics at the Atlanta Web Design Group Meetup on November 11

On November 11 at 7:00pm, Matthew Turland will speak to the Atlanta Web Design Group about PHP, covering basics of the language and best practices from a designer’s perspective. This will include basic output, variables, conditional branches, loops, output modularization using includes, coding style, and escaping output for security purposes.

Matthew is the Lead Programmer for a Web application service provider, is Zend PHP Certified, and works with PHP and MySQL on a daily basis. He’s also a member of the PHP Community organization and serves as an organizer for the Acadiana Open Source Group. You can also read his blog at http://ishouldbecoding.com/.

There will be a 30-40 minute presentation followed by Q&A and discussion.

You must RSVP at Meetup.com for this meeting.

php|works and PyWorks in Atlanta November 12-14!

Atlanta PHP invites you to join us at php|works and PyWorks in Atlanta, GA November 12 through 14!

Atlanta PHP user group members receive $100 off the price of registration!

The publishers of php|architect and Python Magazine, are proud to invite you to php|works and PyWorks, two great conferences that will take place in Atlanta, GA, USA, between November 12 and November 14.

With over 65 talks in 5 tracks, 10 tutorials and great networking events and parties, php|works and PyWorks represent a unique opportunity to not only hone your technical skills, but also meet and interact with members of a vibrant community of developers from all walks of life. And remember—your attendance fee covers access to both conferences!

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.

| View | Download

This year, I’m giving a talk at the main conference, as well as moderating a discussion at the ZendCon Unconference, coinciding with the main conference. While it’s a shame that Zend does not open up the Uncon—perhaps even for a small fee—to the general public (you must be a registered ZendCon attendee to attend the Uncon), it is good that they’re opening up the space for anyone attending the conference to share ideas through presentation and discussion in an open forum. The Uncon is the community space and the place to be if you want to engage the PHP Community while at ZendCon.

The “round-table” discussion I’m moderating at the Uncon is titled—with tongue firmly planted in cheek—“PHP Developers’ Groups: Cat Herding 101.” User group leaders and volunteers will likely agree with me that organizing meetings often feels like herding cats. This discussion is primarily for user group leaders and volunteers, but it’s not exclusive. It’s open to everyone who would like to listen, learn, and participate in discussion about planning for user group meetings and events, and how to reach out and communicate with your user group members and the local developer community in your area. If you’ve ever had an interest in starting a user group, by all means, please be sure to attend! The user group discussion will take place on Wednesday, September 17th at 5:15pm in the Uncon space.

At the conference proper, I’ll be giving my “Distribution and Publication With Atom Web Services” presentation. This is the second time I will have given this talk, and it has been greatly improved since I gave it at DC PHP earlier this year. The previous incarnation of this talk was geared more towards developers, but this time, I think the presentation will be of interest to both programmers and managers alike, since I not only describe in technical detail how Atom works, but I also give high-level information explaining how Atom Web Services may be beneficial to your business or organization. I make the case for why Atom is important for any application that distributes or publishes content.

As for the remainder of the day today, I’ll be hanging out in sunny California, possibly taking a day trip into San Francisco to walk around and sight-see.

Hope to see you at the conference!

You may recall PHP Groups being created over a year ago for the purpose of networking together the leaders and organizers of PHP user groups around the world. I’ve been very bad about keeping things moving on this front, but I want to pick things back up and get us talking again. I also want to get us back on track for the mission of this group:

PHP Groups networks PHP user groups into a tighter community, provides a means to share information and resources among its community members, and aids in the formation of new PHP user groups.

In the near future, we’ll have more discussion about what we can do to progress toward fulfilling this mission.

In the meantime, if you help with the organization of your local PHP user group in any way, feel free to join the ug-admins mailing list or subscribe to the ug.admin news group at php.net:

ug-admins-subscribe [ at ] lists.php.net
news://news.php.net/ug.admins

Also, look to this list for announcements about meet-ups of user group leaders and organizers at upcoming conferences!

And, as always, I’m lurking in #phpgroups on Freenode IRC, so feel free to join me, if you like.

Thanks to all who attended!

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.

| View | Download

In previous years at OSCON, I’ve stuck mainly to the PHP track. This is because I have a lot of friends who are speakers, and so I’ve attended their talks to learn from and support them. This year, though, I’ve decided to focus on some of the other languages represented here, particularly Python and Erlang. This morning, for example, I attended Steve Holden’s Python In 3 Hours tutorial. Tomorrow, I’ll be attending the Practical Erlang Programming tutorial, and later this week, I’ll get Just Enough C for Open Source Projects.

So, today, one of the more interesting features I learned that Python supports is the concept of closures. Here’s a simple example from the tutorial:

# Closures example
 
def adder(n):
  def add(m):
    return m+n
  return add
  
add20 = adder(20)
 
print add20(2) # should print 22
 
l = []
for i in range(100):
  l.append(adder(i))
 
print l[13](22) # should print 35

FYI: There’s been some discussion surrounding a recent patch proposal to add closures and lambda functions to PHP.

At any rate, it’s good to be back at OSCON this year, catching up with old friends, making new friends, and expanding my knowledge of open source languages.

By the way, I’ve brought along with me 10 elePHPants who need good homes. If you want one, it’s yours. You just have to find me in person and let me know. They’re first-come, first-serve.

First, the pet peeve: I cannot stand it when someone uses a GET request to modify information. I don’t care how secure it is because you’re checking my session and login details, sending a GET request to /direct_messages/destroy/30264861 should not do anything other that retrieve the resource located there. If using GET, the user agent thinks it’s a safe action and will not know that it should warn me that the action I’m about to take could modify information. CSRF anyone?

Come on, people! GET is a safe method. Client-side developers (among others) would do well to learn this.

Consequently, there is no resource at that location, and that also peeves me. Instead, I get a weird 302 Moved Temporarily HTTP redirect that also includes a Status: 302 Found header. WTF? Come on! It’s 2008. RFC 2616 has been out for nine years now. Is there anyone using Twitter on a user agent old enough that it only works for HTTP 1.0? (I’ll wager that I’ll get responses from people about how some mobile browsers only understand HTTP 1.0.)

This leads me to the second thing I want to discuss: HTTP redirections.

Historically (in HTTP 1.0), HTTP had two status codes for redirection: 301 Moved Permanently and 302 Moved Temporarily. However, 302 became misused and abused by user agents that didn’t follow the spec, which stated: “If the 302 status code is received in response to a request using the POST method, the user agent must not automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.” Instead, user agents would often simply use a GET request on the value of the Location header, redirecting the user without warning.

Take a moment now to think about this. Why would the user agent send a GET request for the value of the Location header without asking the user if it’s okay? Because the user agent thinks it’s safe to do so. Remember my earlier rant?

Nevertheless, the user agents weren’t supposed to be behaving this way, but developers used 302 Moved Temporarily as the common method for redirecting after POST actions, and following the spec would make for a cumbersome user experience, especially if I had to approve every single redirect that occurs after I POST something. (This actually happens on mobile browsers quite frequently, since the mobile browser—on my phone, at least (a RAZR)—properly implements the expected behavior, thus making a crappy experience for me.)

So, to rectify the situation, HTTP 1.1 introduced 303 See Other and then later 307 Temporary Redirect (changing the meaning of 302 to Found).

The 303 See Other status code unambiguously states that the value of the Location header “SHOULD be retrieved using a GET method” and that the “new URI is not a substitute reference for the originally requested resource.” That is, if the user agent originally used POST to send data, then the server can tell the user agent to safely redirect to another resource using GET, and the new resource should not be expected to act on the data sent in the original POST request.

Likewise, the 307 Temporary Redirect status code unambiguously states that if it is “received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.” So, if I POST a form to a server that sends back a 307 Temporary Redirect, then the user agent should ask me whether I want to proceed. If I say “yes,” then the user agent will proceed to POST the data to the URI identified by the Location header.

So, a couple rules of thumb: 302 Found is still the de-facto redirection method, though it may not mean what you want it to mean or behave properly on all user agents. If you want to process a POST request and then safely redirect the user agent using GET, use 303 See Other. If you want to redirect a POST request (that is, send the posted data to a different location), use 307 Temporary Redirect. If the original request was GET or HEAD, and you simply want to redirect the user agent, then either 302 Found or 307 Temporary Redirect are proper, though I prefer the 307.

To explicitly tell user agents (and particularly search engines and proxies) that something has moved permanently and that they should update their links, use 301 Moved Permanently .

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.

| View | Download

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.

| View | Download

As a speaker at conferences, what often interests me most is in meeting with people, making new friends, and catching up with those I only get to see a few times a year (if that many) at conferences. I’m fortunate to have played a small role in helping to start and keeping alive the PHP Community project through the #phpc IRC channel on Freenode, and it is the members of the Community that I’m so proud to see attending conferences, taking initiative in organizing impromptu extra-curricular events at conferences, and even welcoming in new faces and new ideas. The Community ranges from end-users of PHP to core developers who take part in making decisions regarding the future of our beloved language.

At this year’s php|tek, I saw the Community come together in an exciting way, and, really, I think they provided a lot of the energy and enthusiasm that took us through the whole week, getting even the other attendees excited about the things going on at the conference and in the greater PHP community. From Christian Flickinger’s homemade buttons to Damien Seguy’s new batch of PHP and Oracle elePHPants to the #phptek channel on Freenode to tons and tons of Twitter updates to nightly trips to Shoeless Joe’s (and even the conference meme of changing the name of the bar on each new tweet), the Community played a large part in providing the conference with a fun and exciting atmosphere, and I commend Marco, Sean, Paul, and Arbi at php|architect for allowing and even encouraging the Community to involve themselves in this way. You guys truly rock!

The Community members who attend are really the unsung heroes of the conference, in my opinion. They aren’t necessarily speakers (though some are). They aren’t the PHP thought leaders (again, some are). Their companies don’t often pay their way to conferences. They make do however they can by organizing road trips, sharing rooms, etc. so that they can attend the conferences. I think this creates even more camaraderie and a closer bond between Community members. Without their presence, the conference dynamic would be terribly lacking.

So, while I’m now back home with my family, who I dearly missed while away, I raise my glass to the PHP Community members and to the organizers of php|tek. You know who you are. You all made this conference truly memorable for me.

Thank you, and I hope to see you again soon at another conference.

The 204 No Content response is useful in a web service when you want to return a success message but do not want to return a message in the body or do not have a body to return. In my personal experience, I use this when DELETE requests are sent to an Atom web service. If the resource is successfully deleted, the service returns a 204 No Content status message. This tells the client that the deletion was successful, and that’s really all the client needs to know. There’s nothing to return because it was deleted.

However, even outside of the web services realm, the 204 No Content status actually means something to a user agent (browser). The HTTP specification (RFC 2616) states the following about the 204 No Content status code:

If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent’s active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent’s active view.

This means that, if I have an HTML form and submit it, then, if the server returns a 204 status code, the browser should not refresh the form or take me to another page. The document view does not change, and I remain at the form. All of the data I entered remains unchanged. All browsers I tested support this, but, in practice, it is not very useful since there’s no indication to a user that anything happened on the server side.

However, consider the use of 204 No Content in an Ajax application. If the Ajax library used simply looks for a success message of 204 in response to the requests it sends, then it can present a success message to the user without changing any of the UI elements, as this response intends. This is also useful because the service doesn’t need to send back any data; it needs only tell the client that the request was successful.

On the other hand, with a 205 Reset Content response, the intent is to tell the client to clear the content from the form or to refresh the UI. That is, I could fill out a form, click the submit button, and the form I am currently working on would refresh to its default values if the client receives a 205 response. According to the HTTP spec, a 205 response means:

The server has fulfilled the request and the user agent SHOULD reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate another input action.

The problem is that I have not found a browser yet that supports this behavior. Browsers either treat a 205 like it’s a 204, or they simply treat it as a 200. This does not mean, though, that Ajax applications cannot properly respect a 205 response. In an Ajax application, if the client receives a 205 response (instead of a 204 response), then the UI elements should change back to their default state.

In RESTful Web Services, Richardson and Ruby make this distinction between 204 and 204:

In data entry terms: 204 is good for making a series of edits to a single record; 205 is good for entering a series of records in succession.

In my simple browser test to see what browsers supported 204 and 205 on forms (without using any Ajax), here’s what I found:

Firefox 2.0.0.14
  - 204 - supported
  - 205 - treated like 204

Safari 3.1.1
  - 204 - supported
  - 205 - treated like 200

Opera 9.27
  - 204 - supported
  - 205 - treated like 200

Internet Explorer 7 (7.0.5730.13)
  - 204 - supported
  - 205 - treated like 200

Internet Explorer 8 beta 1 (8.0.6001.17184)
  - 204 - supported
  - 205 - treated like 200

Firefox 3 beta 5
  - 204 - supported
  - 205 - treated like 204

Since I know I’ll be asked this question, to send back a 204 or 205 response with PHP, see the PHP manual on the use of the header() function.

I was wondering if there was a response status to allow a large file to be “served” in parts and in just one response?

While I’ve never done this myself, I did some research to see how it might be done, and I’ve come up with a solution that I wish I could call clever, innovative, and many other words that make me sound like I came up with a smart solution, but the reality of it is that HTTP was made to support this behavior, so I’ll just tell you how to do it with standard HTTP.

First of all, let’s create a scenario. Say I want to request a very large file from a service, but before I do so, I want to find out exactly how large it is and whether the service supports “range requests.” To do this, I make a HEAD request to the large resource I want to retrieve. The HEAD method is a standard HTTP method that acts as if I’ve made a GET request, but it returns only the headers and not the body. This allows me to find out some information about the resource without actually taking the time or using the bandwidth to download it. For example, I can read the Content-Length header and determine the size of the resource.

Another header of great importance is the Accept-Ranges header. If it’s present, it may contain a value of “bytes.” If so, I know that I can make a GET request and request a byte range to retrieve only those bytes. This is the first important key component:

If you are building a service that accepts byte range requests, let clients know by providing the Accept-Ranges header in response to GET and HEAD requests.

So, now, I know I can make a range request to the service, which I do by sending a standard GET request including a Range header that specifies the range of bytes I’m requesting, like so: Range: bytes=0-999. The service should then respond with with a 206 Partial Content status code, a Content-Range header, and the requested range of bytes. This is the second key component:

If a client makes a request of your service with a Range header, return a 206 Partial Content response containing a Content-Range header and the requested range of bytes for the resource in the body. The Content-Length value should be the length of what is actually returned and not the full length of the resource.

From then on, it’s a matter of the client continuing to make requests until it has retrieved all of the bytes it wishes to get from the resource. If the client makes a range request that is out of bounds—that is, none of the range values overlap the extent of the resource—the service should respond with a 416 Requested Range Not Satisfiable status.

I should note that the service cannot force the client to make a range request. It is entirely up to the client to make such requests, so the service should honor all standard GET requests that do not contain a Range header by sending back the full representation of the requested resource. If your service allows range requests, it is to your benefit to tell the client with an Accept-Ranges header. If you want to explicitly tell the client that you do not allow range requests, send a value of “none” back with the Accept-Ranges header.

Since I learn best by looking at real-life examples, I’ll provide one for you. Here’s a real example making range requests with Flickr. I’ve removed some of the headers for simplicity and clarity.

HEAD /2390/2253727548_a413c88ab3_s.jpg HTTP/1.1
Host: farm3.static.flickr.com

HTTP/1.0 200 OK
Date: Mon, 05 May 2008 00:33:14 GMT
Server: Apache/2.0.52 (Red Hat)
Accept-Ranges: bytes
Content-Length: 3980
Content-Type: image/jpeg

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

GET /2390/2253727548_a413c88ab3_s.jpg HTTP/1.1
Host: farm3.static.flickr.com
Range: bytes=0-999

HTTP/1.0 206 Partial Content
Date: Mon, 05 May 2008 00:36:57 GMT
Server: Apache/2.0.52 (Red Hat)
Accept-Ranges: bytes
Content-Length: 1000
Content-Range: bytes 0-999/3980
Content-Type: image/jpeg

{binary data}

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

GET /2390/2253727548_a413c88ab3_s.jpg HTTP/1.1
Host: farm3.static.flickr.com
Range: bytes=1000-

HTTP/1.0 206 Partial Content
Date: Mon, 05 May 2008 00:37:54 GMT
Server: Apache/2.0.52 (Red Hat)
Accept-Ranges: bytes
Content-Length: 2980
Content-Range: bytes 1000-3979/3980
Content-Type: image/jpeg

{binary data}

1. First, make sure you have the Apple Xcode tools installed, along with X11.app.
   
   
2. Since Umbrello requires KDE, you’ll have to install KDE. You can follow these instructions to install KDE with either Fink or MacPorts. I chose to go with MacPorts, and the command is simple:
   
   $ sudo port install kde
   
   The KDE installation can take quite a while, depending on your system. On my PowerBook G4, it took well over 7 hours. My Intel iMac was considerably shorter, but still took a couple of hours.
   
   

1. Once KDE is installed, you should have all the necessary libraries to build Umbrello. Download the Umbrello source and get to work:

   $ wget http://prdownloads.sourceforge.net/uml/umbrello-1.5.8.tar.bz2?download
   $ tar jxf umbrello-1.5.8.tar.bz2
   $ cd umbrello-1.5.8
   $ ./configure --prefix=/opt/local --with-qt-includes=/opt/local/include/qt3/ \
   > --with-qt-libraries=/opt/local/lib/qt3/ --with-extra-libs=/opt/local/lib \
   > --with-extra-includes=/opt/local/include --without-arts
   $ make
   $ sudo make install

   Umbrello is now ready to run. To run it, just open X11.app and enter the command:

   /opt/local/bin/umbrello

   That’s all there is to it!

   Umbrello seems to be just the tool I needed. It appears to be a much more intuitive and easier-to-use UML modeling program than any others I have tried, and it will generate PHP 5 code. It doesn’t generate everything quite as well as I had hoped, but it gets the class stubs in place, and I can go back in and correct things for my coding standards and update the comment blocks as needed.

   Also, another observation: applications built using the KDE libraries (i.e. Umbrello) do not appear to run as clunky on the Mac through X11 as those using GTK. They actually run quite smoothly.

   
   ]]> http://benramsey.com/archives/umbrello-uml-modeler/feed/ http://api.feedburner.com/awareness/1.0/GetItemData?uri=ramsey&itemurl=http%3A%2F%2Fbenramsey.com%2Farchives%2Fumbrello-uml-modeler%2Fhttp://benramsey.com/archives/umbrello-uml-modeler/ http://feeds.feedburner.com/~r/ramsey/~3/277788094/ http://benramsey.com/archives/http-status-201-created-vs-202-accepted/#comments Fri, 25 Apr 2008 18:48:55 +0000 Ben Ramsey http://benramsey.com/archives/http-status-201-created-vs-202-accepted/ Continuing my series on HTTP status codes, I’d like to talk today about the use of the 201 Created and 202 Accepted codes.

   I should make a point of clarification first, though. When I’m discussing the use of status codes, I have in mind Web services applications with perhaps rich clients that interface with them and not necessarily standard, browser-based Web apps. Browsers should be able to handle these status codes, but they are not necessarily the richest clients to use as an interface to your Web service, so they may not be able to handle the responses as intended.

   Moving along…

   Recently, while designing an application that uses the Atom Publishing Protocol, I found myself using the 201 Created status code as a response to successful POST requests for creation of new content in the service. In the body of the response, I would return a full representation of the newly created resource, and I would include a Location header with a URI that points to the location of the newly created resource. (Instead of returning a full representation of the created resource, you may return a list of URIs pointing to locations for the resource(s) created.)

   In general, this is a good practice, though most of us find ourselves returning the standard 200 OK code. (Using 200 OK is still acceptable, though I’ll have more to say on that in a future post.) However, I ran into a problem when I realized that the resource itself does not yet exist, nor might it ever exist; it all depends on our business rules, which require various processes to occur before we “publish” the content. So, the 201 Created response is misleading to the client because nothing has been created yet, and the representation of the resource is inaccurate since the resource does not yet exist. The resource is really in a pending state.

   Enter the 202 Accepted status code.

   I decided to use the 202 Accepted status code as the more proper response to these types of requests. 202 Accepted means that the service successfully accepted the request and there are, as of yet, no problems with it (i.e. no immediate data validation problems), but it can’t create the resource until it does further processing. This response does not promise that the resource will be created, though. So, it’s perfect for pending requests, since a pending request could be rejected while it’s being processed.

   The HTTP spec says that a 202 Accepted response SHOULD include an indication of the request’s current status. To this end, for our service, I have it return an Atom Entry Document with content that describes what’s going on, i.e. the request succeeded but requires further processing before it can be published. It may also be beneficial to clients to include a Location header with a URI that can be used later to check on the status of the request.

   When the client checks the status URI later, if the item is still pending then the status URI might return a 200 OK response with an entity body describing this. If the resource has been created, then perhaps the status URI would return a 201 Created response with a Location header pointing to the location of the new resource. If the item was not created for some reason, then perhaps the status URI would return a 410 Gone response. In this case, you should include an entity body explaining why the resource is gone, i.e. “We were unable to create this resource due to processing errors.” A 404 Not Found response would also be acceptable, but the 410 Gone response implies permanence; the requested resource is gone for good.

   The status URI described here is a temporary URI used only for checking on the status of the request. It would eventually be unavailable after the resource has been created or rejected, but the time frame for this is up to you.

   
   ]]> http://benramsey.com/archives/http-status-201-created-vs-202-accepted/feed/ http://api.feedburner.com/awareness/1.0/GetItemData?uri=ramsey&itemurl=http%3A%2F%2Fbenramsey.com%2Farchives%2Fhttp-status-201-created-vs-202-accepted%2Fhttp://benramsey.com/archives/http-status-201-created-vs-202-accepted/ http://feeds.feedburner.com/~r/ramsey/~3/275647430/ http://benramsey.com/archives/http-status-100-continue/#comments Tue, 22 Apr 2008 20:26:57 +0000 Ben Ramsey http://benramsey.com/archives/http-status-100-continue/ As a self-described HTTP status code pedant and an architect of RESTful Web services, I’ve spent a great deal of time researching and thinking about the proper use of HTTP status codes in Web applications. It occurs to me that many people use status codes in their applications in ways that I find improper, so I’ve decided to start up a series of blog posts to talk about select status codes and how they might appropriately fit within your Web applications, specifically in a RESTful manner. Consider these “Ben’s HTTP Status Codes Best Practices.”

   I won’t be covering these status codes in any particular order. However, the first code up is 100 Continue merely because I’ve been thinking about it lately.

   The 100 Continue status code is an informational response that tells the client application it can continue sending the request. In short, the client can make an abbreviated request of the service to check whether or not it should continue making the full request. The service can then respond either “yes” (100 Continue) or “no” (417 Expectation Failed) with an explanation of why not. In RESTful Web Services, Richardson and Ruby refer to this as a “look-before-you-leap” (LBYL) request.

   This is helpful in situations where the client might want to post or put a very large file to the service but wants to ensure that the service will accept it before actually sending the file. Consider the following request:

   POST /content/videos HTTP/1.1
   Host: media.example.org
   Content-Type: video/mp4
   Content-Length: 105910000
   Authorization: Basic bWFkZTp5b3VfbG9vaw==
   Expect: 100-continue

   In this case, the client is attempting to post an MPEG-4 video that is 101MB. The client sends this request to your service without the video in the body, and it includes the Expect: 100-continue header. Let’s say your service limits uploads to 100MB. In that case, you would return a 417 Expectation Failed including a reason for the failure in the body of the response.

   By now, you can probably see how this can be extended to apply to any of the other headers. For example, a client can try a POST or a PUT request first just to see if its authorization succeeds. If it does, your service would return 100, letting the client know it may proceed with the request. Likewise, the client might want to determine whether the service will accept a video/mp4 file before sending it. The list goes on.

   It should be noted that the service shouldn’t require the client to use a LBYL request, but it can be helpful to a client so that it doesn’t attempt to send something that would fail at the service anyway.

   I’m considering implementing these kinds of responses in a service I’m building, so I’ll let you know how it goes.

   
   ]]> http://benramsey.com/archives/http-status-100-continue/feed/ http://api.feedburner.com/awareness/1.0/GetItemData?uri=ramsey&itemurl=http%3A%2F%2Fbenramsey.com%2Farchives%2Fhttp-status-100-continue%2Fhttp://benramsey.com/archives/http-status-100-continue/ http://api.feedburner.com/awareness/1.0/GetFeedData?uri=ramsey