Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Imagine, there is a resource, for example event. User is able to get list of events in HTML format. He should be able to view that list in two ways: as a list and as a calendar. How the API should respond to this options?

The simplest approach, I think, is to pass some parameter to index action to determine which type of presentation to use, but I don't like it. Don't know why, it is not RESTful for me.

What do you think, do I misunderstood something and should keep things simple or there is a better approach?

share|improve this question
up vote 1 down vote accepted

If the content is identical, it's unclear what "differences" would be seen in list vs. calendar. If the result is a JSON or XML document, there should be no discernible difference.

if the result is an HTML page, where formatting is part of the results, then the path is the correct thing to do, since the content is different.

You have several choices.

  1. Path changes. "/path/to/resource/view/id/" works well for us. Our views include "html", "xml" and "json".

    However, your "list" vs. "calendar" may or may not be the same content, in the a single format, and a different organization. So you have a number of issues tangled up together in your question.

  2. Query String changes. This: "?view=calender" or "?view=list".

  3. Fragment changes. This: "#calendar" or "#list". These can work well in your case, since the two views seem to have different content.

share|improve this answer

The technically correct option would be to have the application look at the http accept header. This is typically so non-obvious that no one but hardcore RESTheads use it and go with url switches which are a reasonable compromise.

share|improve this answer

The way you are describing it, it would seem the list and the calendar are different resources and should have different urls.

Even if they are currently populated using the same data, I think I would lean towards viewing them as separate resources, at least partly because it any options to view them as separate representations (query string or fragments) seem a little un-RESTful.

Also, if the data behind the list and calendar diverge in the future then viewing them as separate representations of the same resource will fall apart.

share|improve this answer
I thought about creating two resources, but it is unclear, what is the difference between them that makes possible to consider them separately. – Dmitry Maksimov Mar 22 '11 at 18:45

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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