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:
Creating an item would be a PUT to a URI like:
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
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.