Có một danh sách nào đó đề xuất các khung REST dựa trên Python khác nhau để sử dụng trên các máy chủ để viết API RESTful của riêng bạn không? Tốt nhất là với ưu và nhược điểm.
Xin vui lòng thêm các khuyến nghị ở đây. :)
Câu trả lời:
Một điều cần cẩn thận khi thiết kế API RESTful là sự kết hợp giữa GET và POST, như thể chúng là cùng một thứ. Thật dễ dàng mắc lỗi này với các khung nhìn dựa trên chức năng của Django và bộ điều phối mặc định của CherryPy , mặc dù cả hai khung công tác hiện đang giải quyết vấn đề này ( các khung nhìn dựa trên lớp và Phương thức tương ứng).
Động từ HTTP rất quan trọng trong REST và trừ khi bạn rất cẩn thận về điều này, cuối cùng bạn sẽ rơi vào một mô hình chống REST .
Một số khung làm cho nó đúng là web.py , Flask và Chai . Khi kết hợp với thư viện mô phỏng (tiết lộ đầy đủ: Tôi đã viết nó), chúng cho phép bạn viết các dịch vụ web RESTful đẹp:
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()Logic của dịch vụ chỉ được triển khai một lần và lựa chọn biểu diễn chính xác (Tiêu đề chấp nhận) + gửi đến chức năng kết xuất (hoặc mẫu) phù hợp được thực hiện một cách gọn gàng, minh bạch.
$ 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!Cập nhật (tháng 4 năm 2012) : thêm thông tin về các chế độ xem dựa trên lớp của Django, các khung công tác Phương pháp Cherry và của Flask và Chai. Không tồn tại trở lại khi câu hỏi được hỏi.
Ngạc nhiên không ai nhắc đến bình .
from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello():
return "Hello World!"
if __name__ == "__main__":
app.run()Chúng tôi đang sử dụng Django cho các dịch vụ web RESTful.
Lưu ý rằng - ra khỏi hộp - Django không có xác thực đủ chi tiết cho nhu cầu của chúng tôi. Chúng tôi đã sử dụng giao diện Django-REST , giúp ích rất nhiều. [Chúng tôi đã tự lăn lộn vì chúng tôi đã tạo ra rất nhiều tiện ích mở rộng đến nỗi nó trở thành một cơn ác mộng bảo trì.]
Chúng tôi có hai loại URL: URL "html" triển khai các trang HTML hướng đến con người và URL "json" thực hiện xử lý theo định hướng dịch vụ web. Chức năng xem của chúng tôi thường trông như thế này.
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 responseVấn đề là chức năng hữu ích được bao gồm trong hai bài thuyết trình. Bản trình bày JSON thường chỉ là một đối tượng được yêu cầu. Bản trình bày HTML thường bao gồm tất cả các loại công cụ hỗ trợ điều hướng và các đầu mối theo ngữ cảnh khác giúp mọi người làm việc hiệu quả.
Các jsonViewchức năng đều rất giống nhau, có thể gây một chút khó chịu. Nhưng đó là Python, vì vậy hãy biến chúng thành một phần của lớp có thể gọi được hoặc viết trang trí nếu nó giúp.
y = someUsefulThing(...)là "sự lặp lại khủng khiếp", thì tất cả các tham chiếu đến tất cả các chức năng và phương thức là "khủng khiếp". Tôi không hiểu làm thế nào để tránh tham chiếu một chức năng nhiều hơn một lần.
someUsefulThing(request, object_id)là một biểu thức truy xuất dữ liệu. Bây giờ bạn có hai bản sao của cùng một biểu thức ở các điểm khác nhau trong chương trình của bạn. Trong câu trả lời được chấp nhận, biểu thức dữ liệu được viết một lần. Thay thế someUsefulThingcuộc gọi của bạn bằng một chuỗi dài, thích paginate(request, Post.objects.filter(deleted=False, owner=request.user).order_by('comment_count'))và nhìn vào mã. Tôi hy vọng nó sẽ minh họa quan điểm của tôi.
Xem wiki Web Framework của wiki.
Bạn có thể không cần các khung ngăn xếp đầy đủ , nhưng danh sách còn lại vẫn còn khá dài.
Tôi thực sự thích CherryPy . Đây là một ví dụ về một dịch vụ web yên tĩnh:
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())Điều này nhấn mạnh những gì tôi thực sự thích về CherryPy; đây là một ví dụ hoàn toàn hiệu quả, rất dễ hiểu ngay cả với những người không biết khung. Nếu bạn chạy mã này, thì bạn có thể thấy ngay kết quả trong trình duyệt web của mình; ví dụ: truy cập http: // localhost: 8080 / celc_to_fahr? độ = 50 sẽ hiển thị 122.0trong trình duyệt web của bạn.
Tôi không thấy bất kỳ lý do nào để sử dụng Django chỉ để đưa ra một api REST, có những giải pháp nhẹ hơn và linh hoạt hơn. Django mang rất nhiều thứ khác lên bàn, điều đó không phải lúc nào cũng cần thiết. Để chắc chắn không cần thiết nếu bạn chỉ muốn hiển thị một số mã dưới dạng dịch vụ REST.
Kinh nghiệm cá nhân của tôi, fwiw, là một khi bạn có khung công tác phù hợp với một kích thước, bạn sẽ bắt đầu sử dụng ORM của nó, các plugin của nó, v.v. chỉ vì nó dễ dàng và cuối cùng bạn sẽ không bị phụ thuộc đó là rất khó để thoát khỏi.
Chọn một khung web là một quyết định khó khăn và tôi sẽ tránh chọn một giải pháp ngăn xếp đầy đủ chỉ để lộ api REST.
Bây giờ, nếu bạn thực sự cần / muốn sử dụng Django, thì Piston là một khung REST đẹp cho các ứng dụng django.
Điều đó đang được nói, CherryPy trông cũng rất đẹp, nhưng dường như RPC nhiều hơn REST.
Nhìn vào các mẫu (tôi chưa bao giờ sử dụng nó), có lẽ web.py là tốt nhất và sạch nhất nếu bạn chỉ cần REST.
Đây là một cuộc thảo luận trong tài liệu CherryPy trên REST: http://docs.cherrypy.org/dev/progguide/REST.html
Cụ thể, nó đề cập đến một bộ điều phối CherryPy được xây dựng có tên là MethodDispatcher, gọi các phương thức dựa trên các định danh động từ HTTP (GET, POST, v.v.).
Vào năm 2010, các cộng đồng Pylons và repoze.bfg đã "hợp lực" để tạo ra Kim tự tháp , một khung web dựa chủ yếu vào repoze.bfg. Nó giữ lại các triết lý của khung công tác mẹ và có thể được sử dụng cho các dịch vụ RESTful . Thật đáng xem.
Piston là khung rất linh hoạt để tán tỉnh các API RESTful cho các ứng dụng Django.
Có vẻ như tất cả các loại khung web python có thể thực hiện giao diện RESTful ngay bây giờ.
Đối với Django, bên cạnh ngon miệng và pít-tông, django-rest-framework là một triển vọng đáng để đề cập. Tôi đã di chuyển một trong những dự án của tôi trên đó một cách suôn sẻ.
Django REST framework là một khung REST nhẹ cho Django, nhằm mục đích giúp dễ dàng xây dựng các API Web RESTful tự mô tả, được kết nối tốt.
Ví dụ nhanh:
from django.conf.urls.defaults import patterns, url
from djangorestframework.resources import ModelResource
from djangorestframework.views import ListOrCreateModelView, InstanceModelView
from myapp.models import MyModel
class MyResource(ModelResource):
model = MyModel
urlpatterns = patterns('',
url(r'^$', ListOrCreateModelView.as_view(resource=MyResource)),
url(r'^(?P<pk>[^/]+)/$', InstanceModelView.as_view(resource=MyResource)),
)Lấy ví dụ từ trang web chính thức, tất cả các mã trên cung cấp api, tài liệu tự giải thích (như dịch vụ web dựa trên xà phòng) và thậm chí cả hộp cát để kiểm tra một chút. Rất tiện lợi.
Liên kết: http://django-rest-framework.org/
web2py bao gồm hỗ trợ để dễ dàng xây dựng API RESTful, được mô tả tại đây và tại đây (video). Cụ thể, hãy xem parse_as_rest, cho phép bạn xác định các mẫu URL yêu cầu ánh xạ đối với các truy vấn cơ sở dữ liệu; và smart_query, cho phép bạn vượt qua các truy vấn ngôn ngữ tự nhiên tùy ý trong URL.
Tôi bạn đang sử dụng Django sau đó bạn có thể coi django-ngonpie như là một thay thế cho django-piston . Nó dễ dàng điều chỉnh các nguồn dữ liệu không phải ORM hơn piston và có tài liệu tuyệt vời .
Chúng tôi đang làm việc trên một khuôn khổ cho các dịch vụ REST nghiêm ngặt, hãy xem http://prestans.googlecode.com
Vào thời điểm đầu Alpha, chúng tôi đang thử nghiệm mod_wsgi và AppEngine của Google.
Tìm kiếm người thử nghiệm và thông tin phản hồi. Cảm ơn.