是否有一份关于在服务器端使用不同基于python的REST框架来编写自己的RESTful api的推荐列表?最好有正反两面。
请随意在这里添加建议。：）
当前回答
在设计RESTful API时需要注意的是GET和POST的合并，就好像它们是同一件事一样。Django的基于函数的视图和CherryPy的默认分派器很容易犯这个错误，尽管这两个框架现在都提供了解决这个问题的方法(分别是基于类的视图和MethodDispatcher)。
http -动词在REST中非常重要，除非非常小心，否则最终会陷入REST反模式。
一些框架是正确的web.py, Flask和Bottle。当与mimerender库结合使用时(完全披露:它是我写的)，它们允许你编写漂亮的RESTful webservices:
import web
import json
from mimerender import mimerender
render_xml = lambda message: '<message>%s</message>'%message
render_json = lambda **args: json.dumps(args)
render_html = lambda message: '<html><body>%s</body></html>'%message
render_txt = lambda message: message
urls = (
'/(.*)', 'greet'
)
app = web.application(urls, globals())
class greet:
@mimerender(
default = 'html',
html = render_html,
xml = render_xml,
json = render_json,
txt = render_txt
)
def GET(self, name):
if not name:
name = 'world'
return {'message': 'Hello, ' + name + '!'}
if __name__ == "__main__":
app.run()
服务的逻辑只实现一次，正确的表示选择(Accept报头)+分派到适当的呈现函数(或模板)以一种整洁、透明的方式完成。
$ curl localhost:8080/x
<html><body>Hello, x!</body></html>
$ curl -H "Accept: application/html" localhost:8080/x
<html><body>Hello, x!</body></html>
$ curl -H "Accept: application/xml" localhost:8080/x
<message>Hello, x!</message>
$ curl -H "Accept: application/json" localhost:8080/x
{'message':'Hello, x!'}
$ curl -H "Accept: text/plain" localhost:8080/x
Hello, x!
更新(2012年4月):增加了关于Django基于类的视图，CherryPy的MethodDispatcher和Flask和Bottle框架的信息。问这个问题的时候两者都不存在。
其他回答
我真的很喜欢樱桃皮。下面是一个基于rest的web服务的例子:
import cherrypy
from cherrypy import expose
class Converter:
@expose
def index(self):
return "Hello World!"
@expose
def fahr_to_celc(self, degrees):
temp = (float(degrees) - 32) * 5 / 9
return "%.01f" % temp
@expose
def celc_to_fahr(self, degrees):
temp = float(degrees) * 9 / 5 + 32
return "%.01f" % temp
cherrypy.quickstart(Converter())
这强调了我真正喜欢CherryPy的地方;这是一个完全可行的例子，即使对不了解框架的人来说也是可以理解的。如果你运行这段代码，你可以立即在浏览器中看到结果;例如，访问http://localhost:8080/celc_to_fahr?degrees=50将在您的web浏览器中显示122.0。
如果你正在使用Django，那么你可以考虑Django - tasttypie作为Django -活塞的替代方案。它比活塞更容易调优到非orm数据源，并且有大量的文档。
我们将Django用于RESTful web服务。
请注意，Django没有足够细粒度的身份验证来满足我们的需求。我们使用了Django-REST接口，这很有帮助。[我们后来也推出了自己的版本，因为我们做了太多扩展，以至于它成了维护的噩梦。]
我们有两种URL:“html”URL实现了面向人类的html页面，“json”URL实现了面向web服务的处理。视图函数通常是这样的。
def someUsefulThing( request, object_id ):
# do some processing
return { a dictionary with results }
def htmlView( request, object_id ):
d = someUsefulThing( request, object_id )
render_to_response( 'template.html', d, ... )
def jsonView( request, object_id ):
d = someUsefulThing( request, object_id )
data = serializers.serialize( 'json', d['object'], fields=EXPOSED_FIELDS )
response = HttpResponse( data, status=200, content_type='application/json' )
response['Location']= reverse( 'some.path.to.this.view', kwargs={...} )
return response
关键在于，这两种演示都没有考虑有用的功能。JSON表示通常只是请求的一个对象。HTML表示通常包括各种导航帮助和其他上下文线索，帮助人们提高工作效率。
jsonView函数都非常相似，这可能有点烦人。但它是Python，所以让它们成为可调用类的一部分，或者如果有用的话写装饰器。
看一看
Itty(博客文章) 瓶 web.py 朱诺
我看不出有什么理由只用Django来公开REST api，有更轻、更灵活的解决方案。Django为表提供了许多其他的东西，这些东西并不总是需要的。如果您只想将某些代码公开为REST服务，则肯定不需要。
我个人的经验是，一旦你有了一个一刀切的框架，你就会开始使用它的ORM，它的插件等，因为它很简单，很快你就会有一个很难摆脱的依赖。
选择一个web框架是一个艰难的决定，我不会为了公开一个REST api而选择一个完整的堆栈解决方案。
现在，如果你真的需要/想要使用Django，那么对于Django应用来说，活塞是一个很好的REST框架。
也就是说，CherryPy看起来也很不错，但看起来更像是RPC而不是REST。
看看这些示例(我从未使用过)，如果您只需要REST，那么web.py可能是最好和最干净的。
