Women in Technology

Article:		The REST of the Web
Subject:		Shouldn't you be creating new URIs?
Date:		2005-05-06 14:52:30
From:		lordpixel
I'm not the world's greatest REST expert, but what struck me about your article is that creating new items doesn't create new URIs, which seems to be the usual idiom in RESTful systems. All of your forms go back to the "test5.py" URI, and you put your keys into request parameters. The other REST applications I've seen would model this as a set of URIs eg, The initial page might be: http://someserver.com/myApp/listAll Creating an item would be a PUT to a URI like: http://someserver.com/myApp/item/XXXXX where XXXXX might be the id of the newly created item. Similarly, you'd delete XXXXX by doing a DELETE on that URI and you'd edit it by POSTing to that URI. Similarly, if you did a DELETE on http://someserver.com/myApp/listAll I'd expect it to delete the whole list, not to look at a key in the request parameters and delete a specific item. So to my mind, comparing with the other examples of REST I've seen, whilst you've adopted the part of the model that embraces using HTTP properly (in so far as possible in current browsers), you've kind of ignored the "represent resources as URIs" idea. Of course, it ultimately comes down to opinion as to what constitutes a resource. eg, I can make a counterargument to what I just said: The map is the resource, it's a collection PUT appends to the resource DELETE removes something from the resource GET displays (the whole) resource and POST would edit the resource (somehow) However, I think this breaks down somewhat because you actually use POST to edit existing ITEMS in the collection, not the collection itself. And you would want to be able to GET the whole list or GET an individual item for display. So to me you actually should have two seperate resources, an item and a collection of items. That implies two servlets, one implementing GPPD (GET/PUT/POST/DELETE) for an item and one implementing GPPD for the collection. I think that would be cleaner overall.

Showing messages 1 through 5 of 5.

• Shouldn't you be creating new URIs?
  2005-05-06 18:43:09  jrbriggs [View]
  
  
  Absolutely. Which is exactly what I *have* done in the past when creating stricter REST web services. But for this simple example I decided not to go into that much detail -- which, on reflection, was obviously a mistake, considering your comments and others. ;-)
  
  In any case, the main problem with providing for a proper URI (for example, something like /test5.py/XXXXX) as my example stands, is that I don't think the servlet mapping will pick up test5.py as the correct servlet to call. You probably end up with a Not Found error (I'm on holiday at the moment, so it's a bit hard to check). To create a stricter version, I believe subclassing PyServlet will be required in order to provide for the slightly more complicated uri structure. Unless someone else has a better idea of course.
• Shouldn't you be creating new URIs?
  2005-05-08 12:32:12  nferrier [View]
  
  
  "I don't think the servlet mapping will pick up test5.py as the correct servlet to call."
  
  Errr... no. Just make sure the servlet mapping has a pattern that looks like:
  
  <url-pattern>/test5.py/*</url-pattern>
  
  
• Shouldn't you be creating new URIs?
  2005-05-08 18:23:57  jrbriggs [View]
  
  
  Ack! You're right. But adding the python servlet as a mapping in web.xml does remove a bit of the flexibility (albeit not much) from the whole system.
  
  I had a play with the source code of PyServlet last night, and it's relatively simple to modify so that it will look for the last reference to a ".py" file in the path and then ignore what comes after. Which would allow you to have a catchall url-pattern and not prespecify py servlets.
• Shouldn't you be creating new URIs?
  2005-05-09 02:50:09  nferrier [View]
  
  
  According to cool-uris-don't-change you shouldn't expose the .py anyway. URIs should be logical and not implementation dependant.
• Shouldn't you be creating new URIs?
  2005-05-12 05:48:17  r.p.wilson [View]
  
  
  Aren't you nitpicking? And I think you've missed the point.