Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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?
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:
example.com returns the default view for the top-level resource - your website.aboutus could be a named identifier for a resource in the scope of the top-level CMS.*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.
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?
Yes.
Also, say I go to the URL "http://www.example.com/", what resource am I asking for?
No.
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".
http://www.example.com/aboutus/?format=xml
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.
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.
