I’ve spilled a lot of (virtual) ink in this blog, but almost none of it about what I do all day. That’s because I’ve been working at a startup in “stealth mode” for darn near two years and haven’t been able to really say much about it. Until today.

Today at Evri we’re launching the beta version of our site. If you head to the home page and signup, you’ll get yourself a free set of brand-new shiny credentials that will give you the keys to data-surfing heaven.

The company blog post does a good job of highlighting what we have available, but for the truly lazy I’ll give you the quick highlights.

First, is the home page which gives you a look at entities and their relations as we understand them currently. We start out with lists ranking the top people, places and things. In addition to popularity, you can also see who is rising and falling in popularity over time. All of these lists are clickable and enable our super-whizzy widget which provides a nice way of pivoting between entities, all the while getting related content.

This is one of my favorite parts of the product, as it’s really easy to just get lost wandering around from link to link to see how things are related. It’s like a big six-degrees-of-Kevin-Bacon game, except that you can do with just about anything. Part of that link-hopping experience is visiting specific pages about each entity.

Here you can find more detailed content about an entity. Currently these details comes from Wikipedia, but we anticipate adding several other specific sources of structured content. And of course, these pages link you to other pages, so between the hub-and-spoke visualization and the detail pages you can spend quite a bit of time just data-grazing.

So take it for a spin and have some fun exploring! Give us your feedback (a link is at the top of each page) and let us know what you like and don’t like. Most importantly, stay tuned. This is just the beginning for us, we have some pretty exciting stuff in the works and you won’t want to miss out.

Things have been a bit nutty the last few days–as they are for any release–but it will be worth it for the satisfaction of finally lighting this candle.

Enjoy!

I’ve been on a usability/design kick for about the last six months. Somehow I stumbled across a link to Robert Hoekman Jr’s site which was described as great design books for programmers. I fully recognize the fact that I really don’t have that little spark that good designers have, but I’d like to be better at it than I am. So I’ve been eager to find usability and design books that work for visually-clumsy folks like me. Robert Hoekman’s pair of books, Designing the Obvious and Designing the Moment were wonderful additions to my growing design-for-code-dorks library.

The covers of both books were what initially piqued my interest. Both have very simple white covers. Unlike a lot of design books, this one isn’t about showing off a bunch of pyrotechnics on the cover (see Jenifer Tidwell’s Designing Interfaces which includes a colored version of O’Reilly’s usual animal lithograph). I figured anyone willing to put such a sparse cover on the page was pretty confident about the content inside. I also really liked the fact that the form-factor of both books is smaller than the usual trade paperback and comes in at a very economic 200 pages, or about 1/4″ thick.

Alright, I’ll admit that I was taken in by the author’s use of my favorite font, Gill Sans. I just love this font (it’s the font this blog is set to if you don’t override CSS) because it’s clean and elegant with a minimum–or complete absence–of decorative fuss. Unlike the Pragmatic Programmers or O’Reilly the publisher, New Riders, doesn’t seem enforce a particular font style for their books. Therefore I think it’s safe to assume that the author made a conscious decision to use this font which, at a microscopic level, supports many of the notions of simplicity and cleanliness presented in the books.

Designing The Obvious

His first book, Designing the Obvious focuses on translating from what a user needs to creating workable screen-flows. While I’ve knocked out several smaller design books, I’ve been slowly making my way through Alan Cooper’s seminal About Face in which the concept of goal-oriented design is introduced. Hoekman’s book is the second text I’ve come across that offers a contrasting opinion on goal-oriented design the author calls task-oriented design. Whereas Cooper’s approach is to begin design by understanding a user’s goal within the larger context of their lives or career aspiration, task-oriented design is focused on more immediate desires.

A goal-oriented design might start with something like “Anna is a small-business owner who wants to balance career and family. She needs particular help with payroll for her small three-person company.” A task-oriented design might start with “A user with a small-company must be able to setup employees with a minimum of fuss: perhaps just name, address and social security number”. Hoekman even titles one of his chapters “Understand Users, Then Ignore Them”.

Each chapter is tightly-focused on a single concept and few supporting ones. For example, the chapter titled “Turn Beginners Into Intermediates, Immediately” spends a thrifty thirty-five pages outlining the basic distribution of user expertise (hint: the big fat blob in the middle are the intermediate users) and then enumerating several concrete examples of how to serve the intermediates, how to get the beginners to immediates as quickly as possible, and how to keep the advanced users still engaged.

The ability of Hoekman to outline a concept and back it up with several concrete examples is the real strength of the book. This is not a patterns or recipe book. Similarly it’s not a grand philosophical tome (see Cooper, above). Instead it’s a very practical work intent on getting the ideas across, but leaving plenty of room for the reader to explore on their own.

The fact that he gets such a rich amount of information is such a small package is a testament to the author’s well-thought, lean design approach.

5 out of 5 stars

Designing The Moment

Hoekman’s second title focuses specifically on web application design. Unlike his previous book which is more philosophical and abstract, Designing The Moment is much more concrete. With thirty-one chapters spread out over 220 pages, each chapter is tightly-focused. Those chapters are split up into seven major sections.

The first section is titled Getting Oriented and focuses on getting the user oriented with your site. He delves into how users’ eyes flow over a page, navigation, links and dealing with common web paradigms like tag clouds.

The second section, Learning, provides specifics about getting users “over the novice hump”. This theme was an important one in his first book and here he offers several ways to teach your users about your site.

The third section, Searching, walks you through the pitfalls of search interface design. A common theme in both books is that of a poke-yoka, which means to fool-proof in Japanese. The term was originally derived from Toyota’s Production System which was developed in the ’80’s (note: Toyota is currently kicking serious rear-end in the car biz). Here he uses the term poke-yoka device to mean any mechanism that will help prevent the user from hurting themselves. This is not about treating users as idiots but rather hiding ugly implementation details away from the users if at all possible. For example, you if need users to enter a phone number in a particular format, design a form that makes so that users enter phone numbers in that format. Don’t just give them a text field and then complain when they don’t get it right.

Moving on we get to fourth section, titled Diving In, where we really start to get into the nitty-gritty details of things like media player controls, form layout, wizards, and validation. This is the longest section of the book and meatiest. Again, Hoekman nails the concepts with well-chosen representative examples and solutions.

The fifth section, Participating focuses on the mechanics of features commonly associated with “social-networking” web applications. This chapter ranges from concrete implementation recommendations like how to build user profiles, to more abstract, strategic concepts like how to embrace user feedback and how to channel your most vocal users.

The sixth section, Managing Information, provides some tips on helping users digest your site’s contents. Tips here include how to effectively use syndication, dealing with tags and folksonomies, where drag-and-drop is appropriate and dealing with system notifications.

The final section, Moving On, embraces I concept I first saw articulated in 37Signals’ Getting Real . Don’t build your apps as walled gardens where you make every attempt to keep your users from leaving. This ain’t Vegas you aren’t a casino. Yes, you want to give users another chance to reconsider and you certainly want to know why they’re leaving, but don’t be a jerk about it. This section offers some guidelines for parting ways with your users. I think to design something without this in mind is to the fact that not everyone is going to dig what you’ve built. Let them go easily and don’t make things worse by making parting a painful experience.

I loved this book as much as Hoekman’s first title. Both are handy references I’ll keep nearby.

5 out 5 stars.

On Super Tuesday, I forwent attending the usual Seattle Ruby Brigade meeting and stayed at home glued to the radio and TV keeping up on the primary and caucus results across the nation. I love the Public Radio/TV talking heads, but I was really lacking the overall picture. So I warmed up the Internet tubes and started searching for some helpful at-a-glance snapshot of the state of Super Tuesday.

Here then, is an amateur’s critique of the various infographics I tripped across. What I was looking for was something that would tell me:

• Margin of victory for each candidate
• Percentage of precincts reporting
• The number of delegates available
• The number of delegates each candidate won
• Clear indication of races that have finished, and those that have not.
• I want as much information as I can get in a small space
• I don’t want to navigate through data

The New York Times

So let’s start with New York Times. This tabular graphic came from the New York Times front page:

This one came the closest to the goals I was looking for. The Times doesn’t waste any space on images of either the candidates or the states themselves (something a lot of other graphics couldn’t avoid). I get just about everything I’m looking for on my list, except for the delegates.

From the front page, I followed the “Full Coverage” link to this pictorial table which shows the breakdown by state. The conversion of images to black and white for candidates that have dropped out is a nice visual touch. I don’t mind this too much because the table would still be quite readable without them. This table is essentially the same information as the previous one, except that it shows all of the states and has the additional bonus of indicating states whose primaries haven’t happened yet.

And then, of course, we have the ubiquitous geographic map. This view was predominant one across most of these sites. Many sites touted these things as “interactive” which amazes me that it could be considered a possible selling point. I’ll take “informative” over “interactive” any day of the week thank you.

The Washington Post

This little tidbit was at the bottom of each party’s news column on the Washington Post Politics page. I’m not so hot on the geographic map, but the fact that it was placed at the bottom of a text column instead dominating the page (as many of the maps do) earns this a few points.

Next, we turn to the Post’s “Super Map”, which is a glut of hyperactive mouse-oriented popups. It looks promising, but the popup comments came up too easily and weren’t easily dismissed. While this map gives us some notion of the delegates each state has, I can’t tell which candidate got what portion of delegates. Also states that have declared winners don’t show any margin of victory details. This map takes up the entire screen and doesn’t really earn the space it takes up.

At the bottom of the map was a little trend-line chart for the Democrats. Care to guess when Edwards dropped out of the race?

National Public Radio

This is the table from the front page of National Public Radio’s page. This table gives me most of the things I’m looking for with no space wasted on unnecessary graphics. While we get delegate information, the lack of percentages is unfortunate. This is the only tabular display I found that ordered the per-state results in the chronological order in which the polls will close.

This table was a nice compact little sidebar on NPR’s Super Tuesday coverage page. This is probably the best delegate information I found out of any of the sites surveyed here.

CNN

I have to come clean and admit that I simply can’t stand CNN. It’s always on and has so little useful content. The election coverage I’ve seen to-date has some of the glitziest, lowest-density graphics in their live broadcasts of any I’ve seen. The touch displays are merely a cover up for the fact that the content is empty and newscasters cannot improv. However, I have to give CNN credit with this tabular display. Not fantastic, but at least no wasted space on graphics.

However, this table falls short on a number of counts. The biggest problem is the need to paginate through results. Requiring mouse-overs to get popups on a map is one thing, but clicking through a list of data to find what you’re looking for is simply inexcusable. This is a particularly obnoxious example of failing to making the data dense enough.

From the “Full Coverage” link:

I find the stylized map insulting. The northern border of the United States is not a flat. The state borders don’t line up neatly in rows. Not only does this map have the same faults of the others (low data density, too much interaction required), it’s also simply wrong.

USA Today

The USA Today made it’s name in glitzy, over-wrought graphics and typing the URL in the browser bar I fully expected some useless 3D pie-charts and other such non-sense. I was pleasantly surprised to find this box on the front page:

This is a surprisingly informative view. The densely-packed links dispense with state navigation via map. I don’t mind navigation here so much because I can quickly get to any state. I don’t have paginate through results and I don’t have to float over states whose shapes I can’t remember to find them. Instead, clicking on a well-known state abbreviation link in the navigation bar gives you a nice detailed breakdown:

The inclusion of the advertisement in the outlined space of the first graphic works to draw your attention, but is really a turn-off. It’s only because I was giving each site one click that I continued navigating through the site. Normally, I would have left the site for that reason. To be fair, I understand the these sites have to support themselves with advertising. But putting an ad in the middle of a graphic depicting who we pick as our president in one of the most critical times of our history really cheapens the subject being covered.

MSNBC

Sigh…

By now you’ve probably figured out that I think the inclusion of visual geographic information is superfluous. The state images take a third of each state’s space for information. Other than the letter and color, which indicate the candidate and party, this space doesn’t help me. I can tell that the box is about California because it is titled “California” at the top. The inclusion of state images seems like a weak attempt to “spice up” the presentation of the data.

This graphic gives us the usual percentages, including the percentage of precincts reporting, and the total delegates which is helpful. However, since each state apportions delegates differently, we can’t really tell how important a margin of victory is in a particular state. I can’t really harp on MSNBC for this, nobody included that level of detail in the graphic summaries.

Information Design

One of the things that makes a web application “look” RESTful is the type of URLs it presents. Like many things, whether or not these URLs really meet a particular criteria is a matter of degrees. But anyone who has some basic understanding of a resource-oriented view versus a functional view can tell the extremes apart (e.g. /system?sport=football&team=seahawks&year=2006 vs. /football/seattle_seahawks/2006).

However it’s the in-between URLs that seem to provoke the most heated discussions between the REST-anistas and the non-believers. Those not impressed with REST would argue that all we’re doing is prettying-up our URLs with no real functional improvement. Now I happen to prefer good-looking URLs over ugly ones because I think they are easier to work with. But outside of the aesthetic argument I couldn’t really make a good case for RESTful URL design. However, after a bit of thought, I’ve come up with a theory on how URLs ought to be constructed.

The Theory

Requests for resources have two basic components: the identity of the resource and variation information. Identity is the minimum amount of information required to distinguish one resource from another. Variation criteria is additional information that refines or qualifies the representation of the requested resource. Variation information can include things like:

• type of requester
• content type
• session or user
• portions of the representation

In a proper URL design, identity information should be expressed as a first-class notion. In URLs this is best expressed within the path portion of the URL. This information does not belong in request parameters. This not only makes your URL structure easier to manage mentally, it also stands a better chance of working well with HTTP caches (more on this in a bit) and proxies. Variation information can be expressed by the requester in any combination of headers (e.g. Content-Type) or request parameters.

Hold the query parameters!!!

So why do so many people fall back on request parameters? In the Java world, I think a lot of it comes from people developing applications in a Servlet environment. The servlet specification provides no easy way to access path information. You have to get the request path and split the string by hand. Yecchh. Also, the built-in URL mapping in Servlets leaves quite a bit to be desired. So a lot of folks just fall back on the simple dictionary interface that servlets provide for request parameters. Unfortunately this has bred a lot of bad habits in Java web developers.

I think the other reason this design is prevalent, is the holdover of the first great paradigm shift on the web when we moved from “web sites” to “web applications”. Many of the people writing the first web applications (myself included) tended to view HTTP requests as function or method calls where variable information is passed in as arguments. What many of us failed to realize was that requests for dynamic content didn’t require a different way of structuring URLs. We were still, by and large, asking for things.

There are two problems with the functional approach. The first is that a lot of request parameter information could be better expressed with existing headers. The second is action-oriented view that developers take of these requests which violates a core principle of REST where a finite set of actions are applicable over an infinite set of nouns.

Collections

One place where query parameters make sense are specifying views across collections. This is also known as providing a search parameter. Think of the Most Popular URL In The World, http://www.google.com/q?=. When you search, that ‘q’ parameter is a specification for a filtered view of that top-level Google resource. In other words when you query for http://www.google.com/q?=Led+Zeppelin you’re really asking for all things Led Zeppelin from the Google collection.

On a smaller scale, query parameters are quite appropriate when asking for a filtered view over a collection that has arbitrary dimensions. However, not all views over a collection should use query parameters. For example, in a case like Flickr where tags are first-class aspects of certain resources, /tags/ is expressed as a path segment. When resources are normalized like this, you should favor paths over query parameters. However when you want to select a sub-set of resources out of some larger heap and the way you specify that subset is open-ended, query parameters are a good way to go.

Caching

Perhaps the best rationale I can give you for the RESTful approach is that playing by these rules will allow you to take full advantage of HTTPs built-in caching semantics. When you think about what a cache has to do and all of the rules it has to follow, its main function is identifying and returning cached responses to cacheable requests.

That Wild West Frontier that is the “query parameters” section of a URL can give HTTP caches fits. Heck, by default Squid ignores query parameters for resource identification. You have to go out of your way to get this to work. You could argue that Squid “isn’t doing it right”, but I think it would be more fair to say that Squid is trying to be safe with regard to query parameters. This is similar to the way Google’s Web Accelerator treats URLs with query parameters (i.e. an opaque Pandora’s Box not to be trifled with.)

So keep your URLs clean! Figure out what information you need identify a resource and keep it in the path of the URL. Use headers or request parameters for any of the variation information.

Peter Morville & Louis Rosenfeld

504 pages
2006 O’Reilly Press

I’ve recently become fascinated with some of the “softer” edges of my profession such as user interaction, visual design and information architecture. These are difficult topics to write about because their abstract nature makes it hard to provide useful, tangible information while not treating the subject as a simple set of boiled-down “how-tos”. A couple of weeks ago I picked up this book as a way to delve into more formalized information structure and theory. By and large this book did a good job of rounding-out those areas of knowledge for me.

This book is in its third edition and I couldn’t help feeling at times like the authors were trying to justify that. While the table of contents lists six “parts”, I really felt the book was broken up into three major sections: the first is essentially a multi-chapter treatise on what IA is and why it’s important. The second section is some of the nuts-and-bolts theory, and the third section is about implementing IA with a couple of case studies. Of the three sections, the middle one was the most useful to me and, in my opinion, carried the others.

I understand why the authors would feel compelled to write the first section—the intended audience is no doubt large and would certainly contain a number of skeptics. However I found the voice of these chapters to be a little too earnest and tried to hard to justify the profession. At times I wondered if the authors really had confidence in what they were talking about because they spent so much time justifying their statements. I was a bit surprised at the defensive posture of the opening chapters and can’t help but wonder if other readers won’t start wondering what kind of uphill battle am I in for?

Part two is where I felt like I learned the most—this is the real selling value of the book. Most of the information in this part of the book wasn’t new to me, but this section clearly articulated concepts I had previously only understood in abstract, internal terms. Concepts such as the inverse relation between relevance and recall, labeling, taxonomies, different relation types and thesauri were helpful to learn about in concrete terms. If nothing else, I feel like I’ve become more conversant in these topics.

Part three, by comparison, felt like a bit of a letdown. It was dedicated mostly to strategy and tactics around implementing IA within an organization. I won’t argue that the information covered isn’t worthwhile, but it didn’t seem particularly exclusive to information architecture and therefore, in my opinion, was given far too much ink relative to the content-packed middle section. I also felt like the two case studies given at the end of the book lacked the clarity and energy of the middle section of the book. These did not feel like a particularly satisfying, put-it-all-together summary of the concepts covered.

In all, the core information specific to IA was very enlightening and I can imagine that I’ll be thumbing through those chapters again. Also, I’m not sure I’ve read a professional trade paperback with quite so many cross-references (hint: that’s a good thing). Kudos to the authors for giving the reader lots of pointers to related materials. I just wish I could buy a version that only contained the 120 or so pages that I found most useful.

3 out of 5 stars.

In case the recent posts haven’t made it obvious, I’ve been on a bit of a tear about REST lately. In large part this is due to Leonard Richardson’s and Sam Ruby’s “RESTful Web Services” book that I picked up at RailsConf. One of the thoughts that has been bouncing around in my head is how web service-oriented the book was and, besides a chapter about Ajax, said very little about how REST applied to user-facing web applications.

I wondered to myself, “are browsers so broken that we can’t make REST-ful web applications?” I know that in the last year there have been times that I have really struggled with applying REST consistently to web applications. Things like the sign-up and sign-in process seem like square pegs trying to go into round holes. Should I have just given up on REST?

Before we can answer this question we first have to tackle the sticky question of just what, in practice, makes a web app REST-ful or not. One of the obvious places to start is the URLs of your application. It feels pretty un-RESTful to have URLs like /signup or /signin since these are very verb-oriented—REST prefers an infinite array of nouns with a very constrained set of verbs.

So how do URLs like /signup and /signin become REST-ful? One possibility is looking at what the underlying nouns are for these actions. The act of “signing up” for an account could be modeled as POSTing user information to a noun like /accounts—the resource we are attempting to create with the POST message is an account. Similarly, the act of “signing in” is really the act of creating some authorization within an application. We could POST our credentials to a resource like /sessions or /credentials to create an internal resource representing our session with the site. Now things get a little sticky when strictly adhering to REST-ful guidelines and trying to do authentication. That’s a whole other topic for a different post at a different time. Let’s say that with a little thought, you can create REST-ful URLs that still work quite well within a web application.

The next thing to consider is one of the biggest places where strict adherence to REST falls down: the lack of support for any HTTP verbs beyond GET and POST within (X)HTML. Frankly it’s just shocking that we are in this predicament. I really hope that there’s either a good rationale or funny story for why things are this way. I really really hope that it gets fixed soon. Currently there are two ways around this: Ajax and the “_method” parameter hack a la Rails.

The first technique is reviewed in Richardson and Ruby’s book. It turns out that Ajax-driven applications fit pretty nicely with REST. Other than Safari/Konqueror, browsers can support other HTTP verbs quite easily with XMLHttpRequest. Because the Ajax client code shoulders the bulk of the responsibility for the UI, the backend resources can limit their returned representations to data that the Ajax clients work with. This gets rid of a lot of sticky problems that come with having to render fully-functional pages with each request.

The second technique is essentially a hack, but one that allows to code our resources REST-fully. Frameworks like Rails and Restlet do this for us automatically. Even if you are using another framework or rolling your own, you should be able to apply this little “hack” in a nice little corner of the request-response dispatching code without too much fuss. In short, I’m willing to live with this little turd to keep the rest of my system consistently organized.

OK, we’ve got our nouns squared away with a consistent set of verbs. Well-factored nouns implies a good URI design (how else will we identify resources?) What else do we need to have in place to be REST-ful? Hmmm, how about proper state responsibility? You will often hear people say that REST-ful applications are stateless. I think this misses the point. The HTTP protocol is stateless, but your applications undoubtedly have state. Any app with a shopping cart has state. So the question then becomes, do user-facing web applications have different needs that necessitate a violation of REST regarding state?

The short answer is probably not. By and large your application state is usually server-driven and ideally done via “hypermedia as the engine of application state”. In practice this means that the current state of a user’s shopping cart is probably persisted in a shared store allowing any application node to serve the client’s request. Yes folks, a good bit of why REST guys harp on statelessness is for the sake of scalability.

Things get a little grayer when we want to have small bits of saved state on the client for things like “remember me” features or other quick, token-based identification schemes. I won’t lie to you, I’ve used cookies a lot. I know the strict REST approach decries their use and characterizes them as the root of all internet evil, but if they weren’t so damn useful I’d be in complete agreement. Like real-life, having cookies often is probably not a good thing, but once in a while isn’t going to do any long-term damage.

So, can user-facing web applications be REST-ful? Sure. Are there some compromises to be made along the way? Most likely. Does that mean that REST is an overly-idealistic approach that fails in real-world implementations? I would say not—however, your mileage may vary.

Steve Krug

This book served as an amuse-bouche for my foray in to the softer side of application development: usability, design and information architecture. I have to give big kudos to the author for keeping the book focused and short. He has a pretty succint thesis to get across and doesn’t pad the book unnecessarily to add weight. It’s worth considering that the publisher probably printed the book on really high-quality paper to make the retail price fall in line with other professional titles. Hmmm…

There is nothing terribly earth-shattering about the contents–the cover pretty much covers it. However, I did enjoy the sections covering user-testing, especially the part about doing it on the cheap. I think the mystery of usability has created a market for boutique firms that provide these services at a premium. Once people get hip to DIY usability-testing, I would forsee a “market correction” in the future.

3 out 5 stars.

Leonard Richardson & Sam Ruby

I picked this book up from the Powell’s booth while at RailsConf 2007. I had been following the online manuscript for a while and as soon as I saw that the book was in print I snapped it right up. I wasn’t the only one either. REST was a very hot topic at RailsConf and I saw a lot of other attendees with a copy under their arm.

I’ve been keenly interested in REST for about the last year and a half. I’ve read

Fielding’s dissertation a couple of times and read some good blogs, but really felt like REST was missing a more accessible, canonical resource. After completing this book, I think I’ve finally found one.

The author’s do an excellent job of distilling the principles of REST and describe an imlementation of it they term Resource-Oriented Architecture (ROA) which has specific recommendations. I’m pretty sure that my copy will be referred to time and again and that I will probably eventually re-read its contents. I only wish the authors had done more to address using REST in human-facing web applications, not just web services.

4 out 5 stars.

I first ran across REST in my reading about a year and a half ago. While it took me some time to “get” what REST was, I quickly became a fan. However I’ve found that aside from pure aesthetics, I’ve had a hard time articulating why REST is not only beautiful, but effective. I’ve spent a little more time thinking about REST and I think I may have a couple of concrete arguments for REST that go beyond a simple appreciation of its beauty.

Uniformity of Interface

When resources present a uniform interface, we can take advantage of this simplifying assumption. We can focus more on what we can do with resource rather than how we interact with them. This simple convention takes a lot of churn out of the development and integration process.

Uniformity also constrains system design to the minimum required for distributed computing. Anything else is simply baroque elaboration that provides little to no value (think of SOAP’s SOAPAction directive) and is nearly always at the cost of the uniformity.

Works with HTTP

Assuming that you are going to provide data via the web, you are working within the constraints of HTTP. Since HTTP is an expression of the principles of REST, it is both foolish and counter-productive to go against the grain of HTTP’s architecture. Unfortunately, HTTP is a very misunderstood protocol. It is sad that so few people who develop with HTTP understand it so very little.

One of the least understood parts of HTTP are its caching mechanisms. Not only is caching misunderstood, it is terribly under-utilized. Most developers simply know caching as something to disable at all costs. This reflects an abuse of the protocol and an unnecessary effort expended to go against the grain.

When you express your resources as distinct URLs, you can take advantage of the built-in caching semantics HTTP provides. A large reason (though not the only reason) that many web developers work so hard to turn off caching is because their applications are verb-oriented and tend to operate through one or a few separate URLs.

Similarly, the semantics of content negotiation are also rarely well-understood let alone used in the wild. HTTP’s content negotiation mechanism separates the concerns of what an underlying resource is from how it will be represented. This is a good separation of concerns—a user’s account details are a user’s account details regardless whether they are displayed in HTML, JSON or XML.

Connectivity

Connectivity is the way a web application connects within itself. One of Roy Fielding’s main assertions is that REST uses “hypermedia as the levers of application state”. This is achieved by the linked hypermedia returned by a resource. Connectivity provides further simplifying assumptions about how a site is connected. Instead of relying on complicated specifications like WSDL, consumers of REST-ful applications can use a lot more of a web application based simple guidelines.

The Design Analogy

Let’s try to put resources in terms of object-oriented design. A classic symptom of poor object design is where the functional aspects of the system are the first-class attributes of the system and any “objects” are simply data structures passed from function to function. Good object-oriented design puts the behavior right next to the data with a healthy sprinkling of encapsulation.

You wouldn’t have a single function that took an arbitrary number of parameters that could return an arbitrary type or amount of data or perform an arbitrary functions. The complexity would spiral out of control quickly and you would want to create some kind of taxonomy. In object-oriented design these emerge as objects that describe distinct domain entities. Why shouldn’t this apply to web applications and services?

Your Checklist for Winning REST Arguments Around the Watercooler

So let’s sum this up into something you can print out, cut down to pocket-size and laminate and keep in your wallet:
- REST is about resources. There are an infinite number of these, but a very finite number of things you can do with them.
- This simplifying assumption makes client consumption of data simpler.
- This simplifying assumption makes for cleaner resource design.
- Since you’re using HTTP, you might as well use it correctly. Read the spec!
- REST promotes connectivity. Express the connections between your resources and make your application more discoverable and navigable.
- REST prefers a separation of an abstract resource from its physical representation. This is good design.