I have been trying to understand what it means for a application or library or framework to be RESTful? For example, why is it said that bottle or flask is RESTful whereas cgi + wsgiref is not?
Could you please explain with a minimal code example to describe a RESTful application?
REST is an architecture design pattern; you can read more about the sundry details at wikipedia.
The idea is to attach meaning behind HTTP verbs (GET, POST are two you might be familiar with) in order to affect change of data. The API is accessed using endpoints (URLs) that represent a specific entity or entity groups.
In short, here is how its supposed to work:
GET to fetch information about a specific entity.POST to create new record about a specific entity.PUT update the information of an existing entity.DELETE to obviously delete the record of an entity.Well designed application use HTTP response codes (such as the 200 and the 404 that you are already used to) to indicate the result of an operation against an endpoint.
There is a large amount of material out there on creating RESTful APIs and services, and a healthy debate on how people are doing REST right or wrong. I leave researching these up to you.
Any language that has a HTTP library can be used to expose a REST API for existing data, but there are companies like apigee, mashery and libraries like Google Cloud Endpoints that take care of the menial work for you.
For Python specifically, there are many libraries. One of the most popular ones is Django REST Framework which works with django. There is also Flask-RESTful which uses flask.
There is also this question that discusses more REST frameworks for Python.
That you are asking to “build a RESTful application” shows your confusion. REST is a way to model an interface to an application as a collection of (typically HTTP) resources on the web that respond to standard web verbs in expected fashions (e.g., GET to read, DELETE to destroy, PUT to update). What's more, in a high-quality RESTful interface, the resources link to each other in descriptive ways; the client never needs to invent the names of any resource because it can just follow links (or remember URLs it saw earlier; that's also legitimate). Content negotiation is also A-OK; let the client say what format of representation of the resource is preferred, and let the server provide that if it can.
If an application can act as (or within) a web server while seeing sufficient information about the requests (particularly the method, path and other headers) then it can use that to present a RESTful interface. It has everything it truly needs. Some library stacks make it easier than others by providing more support for the various conventions, but that's just a matter of how much work you have to do yourself as opposed to leveraging that of others.
