My goal is to define a RESTful api using CherryPy (wsgi) + uWSGI + Nginx. I'm wondering how to handle the OPTIONS method, as suggested to me on #python. I was advised that implementing a handler to this method would help the callers to my api to understand what methods are supported, and what methods aren't.
Here's what I've got so far:
#!/usr/bin/env python
import cherrypy
# modules used for data access
import nosql
import dao
class Product(object):
exposed = True
def GET(self, key, *args, **kwargs):
try:
p = Product(nosql.get(key))
return p.json
except:
# return 500 error with traceback if debug
pass
def POST(self, *args, **kwargs):
try:
p = dao.Product(*args, **kwargs)
k = nosql.generate_key(Product.__name__)
nosql.set(k,str(p))
except:
# return 500 error with traceback if debug
pass
def OPTIONS(self, *args, **kwargs):
"""
The question is, what to return here? I'm looking
at the following rfc:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
"""
return "GET, POST"
conf = {
'/': {
'request.dispatch':cherrypy.dispatch.MethodDispatcher(),
},
}
application = cherrypy.tree.mount(Product, config=conf)
The body of the OPTIONS response is not as important, and certainly not as specified, as the headers. As you mention, most clients are really only interested in the methods. Those are specified in the "Allow" response header, which CherryPy helpfully emits automatically when you use the MethodDispatcher. Anything else you might return is really up to you to try to meet the needs of the client's application.