How to map different UI views in a RESTful web application?
- by MicE
Hello,
I'm designing a web application, which will support both standard UIs (accessed via browsers) and a RESTful API (an XML/JSON-based web service). User agents will be able to differentiate between these by using different values in the Accept HTTP header.
The RESTful API will use the following URI structure (example for an "article" resource):
GET /article/ - gets a list of articles
POST /article/ - adds a new article
PUT /article/{id} - updates an existing article based on {id}
DELETE /article/{id} - deletes an existing article based on {id}
The UI part of the application will however need to support multiple views, for example:
a standard resource view
a view for submitting a new resource
a view for editing an existing resource
a view for deleting an existing resource (i.e. display delete confirmation)
Note that the latter three views are still accessed via GET, even though they are processed via overloaded POST.
Possible solution:
Introduce additional parameters (keywords) into URIs which would identify individual views - i.e. on top of the above, the application would support the following URIs (but only for Content-Type: text/html):
GET /article/add - displays a form for adding a new article (fetched via GET, processed via POST)
GET /article/123 - displays article 123 in "view" mode (fetched via GET)
GET /article/123/edit - displays article 123 in "edit" mode (fetched via GET, processed via PUT overloaded as POST)
GET /article/123/delete - displays "delete" confirmation for article 123 (fetched via GET, processed via DELETE overloaded as POST)
A better implementation of the above might be to put the add/edit/delete keywords into a GET parameter - since they do not change the resource we're working with, it might be better to keep the base URI same for all of them.
My question is:
How would you map the above URI structure to UIs served to the regular user, considering that there can be several views per each resource, please? Do you agree with the possible solution detailed above, or would you recommend a different approach based on your experience?
NB: we've already implemented an application which consists of a standalone RESTful API and a standalone web application. I'm currently looking into options for future projects where these two would be merged together (i.e. in order to reduce overhead).
Thank you,
M.
