This all may come across very newbish, but I'm trying to wrap my head around designing a website that is thoroughly RESTful. I understand applying RESTful design to things like Users, Photos, Blog Posts, etc. because I think of them like "objects".

But, what about an "about us" page. What kind of resource is that? Is it even a resource in the RESTful sense of the word? Also, say I go to the URL "http://www.example.com/", what resource am I asking for? The index resource?

  • I think some clarification is needed. What is your end goal. What is the need for restful design. taking restful out of the equation, what need are you trying to satisfy? Commented Apr 12, 2011 at 17:14
  • 1
    The end goal is a complete website. Structuring a website around restful design seems to make sense based on the way the web works. I'm just not sure how to apply that kind of design to things that don't seem like resources, such as an about or contact page. Commented Apr 12, 2011 at 17:25

5 Answers 5


The most common RESTful web site resource pattern I see is to add a view to the URI:

/ resourcetype / identifier [/ view] [/ page] [?filterparams]

When there is no view, you simply serve a default view. In your case:

  • / — a request for example.com returns the default view for the top-level resource - your website.
  • /aboutus — the "About us" view of the top-level resource. Or, alternatively, aboutus could be a named identifier for a resource in the scope of the top-level CMS.*
  • /customers/1/aboutus — this request would indicate an "About us" view scoped to customer 1.

That being said, sometimes it's best to fudge a little for better semantics. For example, StackOverflow uses the RESTful /questions/[id] for questions, but the Ask Question page is /questions/ask which isn't very RESTful (ask is not a questions resource) but makes a lot of sense to use mere mortals.

* In CMS's at the top level, the resource type is often, but not always, removed because it is redundant.


Keep in mind that RESTful design per se is intended to provide a standard by which the web becomes uniformly programmable. It is not always appropriate or useful to shoe-horn your entire human-facing website into pure REST semantics.

When you have resources, considering their representations is useful. It is also important to consider the other design principles of REST, such as statelessnes, and how they impact the performance and usability of your website. But remember that REST is a tool, not a goal. It's a means, not an end.

Use RESTful semantics where useful, after understanding their purpose and benefits, and don't sweat it if your site isn't perfectly RESTful. It would be almost impossible for any non-trivial site in any event.

TL;DR: REST is a tool. Use it when and where it is useful but don't be bound by it.

  • 2
    +1 There's more to rest than URLS.
    – Josh Noe
    Commented Jul 12, 2013 at 14:39
  • Ajax, REST, and external linking to your REST site can be a nightmare. Thank you for your answer.
    – johnny
    Commented Jun 3, 2015 at 16:21

But, what about an "about us" page[?] What kind of resource is that?

Complex. Nothing wrong with a resource that has components, pieces or structure.

Resources aren't "relational database rows" or other atomic things. They're resources.

Document-oriented databases handle this more gracefully because a resource can be larger and more structured.

Is it even a resource in the RESTful sense of the word?


Also, say I go to the URL "http://www.example.com/", what resource am I asking for?


You're asking for the "aboutus" resource. It's possible (but odd) for a resource to be a singleton. No ID and not a "list".


Returns a complex XML document with lots of pieces and parts. Nothing wrong with that.

The index resource?

Doesn't mean much in a "RESTful" sense. The "index" page is for people. An application that uses a RESTful API is designed to request specific kinds of resources.

  • 4
    +1 I'd like to tease an important point out of your answer: REST is a programmable paradigm; it is not necessarily intended for human consumption. Commented Apr 12, 2011 at 17:49

I would keep my view's independent of the back-end. You can ask the back-end for resources such as things that go on the accordion, the navigation bar, and other objects that pertain to the body. However, you should leave the processing of these resource representations to your client code, which will eventually render them as per the requirements.


The resource for "About Us" is ... Us :) er, You. Think about the attributes of You that you want to publicize, and roll those up as a noun with a representation.

Those values don't have to come from a database... it will probably be a bunch of string values, and those can come from config, or maybe even hard-coded in a class.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.