Apakah ada daftar rekomendasi kerangka kerja REST berbasis Python yang berbeda untuk digunakan di sisi server untuk menulis API SISA Anda sendiri? Lebih disukai dengan pro dan kontra.
Silakan menambahkan rekomendasi di sini. :)
Jawaban:
Sesuatu yang harus diperhatikan ketika mendesain API yang tenang adalah penggabungan dari GET dan POST, seolah-olah mereka adalah hal yang sama. Sangat mudah untuk membuat kesalahan ini dengan Django 's pandangan fungsi berbasis dan CherryPy ' s operator default, meskipun kedua kerangka kerja sekarang menyediakan cara mengatasi masalah ini ( pandangan berbasis kelas dan MethodDispatcher , masing-masing).
HTTP-kata kerja sangat penting dalam REST, dan kecuali Anda sangat berhati-hati tentang hal ini, Anda akhirnya akan jatuh ke dalam anti-pola REST .
Beberapa kerangka kerja yang melakukannya dengan benar adalah web.py , Labu dan Botol . Ketika dikombinasikan dengan perpustakaan mimerender (pengungkapan penuh: saya menulisnya), mereka memungkinkan Anda untuk menulis layanan web yang bagus:
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()
Logika layanan diimplementasikan hanya sekali, dan pemilihan representasi yang benar (Terima header) + pengiriman ke fungsi render yang tepat (atau templat) dilakukan dengan cara yang rapi dan transparan.
$ 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!
Pembaruan (April 2012) : menambahkan informasi tentang pandangan berbasis kelas Django, MethodDispatcher CherryPy dan kerangka kerja Flask and Bottle. Tidak ada kembali ketika pertanyaan diajukan.
Terkejut tidak ada yang menyebutkan termos .
from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello():
return "Hello World!"
if __name__ == "__main__":
app.run()
Kami menggunakan Django untuk layanan web RESTful.
Perhatikan bahwa - di luar kotak - Django tidak memiliki otentikasi yang cukup untuk kebutuhan kita. Kami menggunakan antarmuka Django-REST , yang sangat membantu. [Sejak itu kami menggulirkan milik kami sendiri karena kami telah membuat begitu banyak ekstensi yang telah menjadi mimpi buruk pemeliharaan.]
Kami memiliki dua jenis URL: URL "html" yang menerapkan halaman HTML yang berorientasi manusia, dan URL "json" yang menerapkan pemrosesan berorientasi layanan web. Fungsi tampilan kami sering terlihat seperti ini.
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
Intinya adalah bahwa fungsionalitas yang berguna diperhitungkan dari dua presentasi. Presentasi JSON biasanya hanya satu objek yang diminta. Presentasi HTML sering menyertakan semua jenis alat bantu navigasi dan petunjuk kontekstual lainnya yang membantu orang menjadi produktif.
Semua jsonViewfungsinya sangat mirip, yang bisa sedikit mengganggu. Tapi itu Python, jadi buat mereka bagian dari kelas yang bisa dipanggil atau tulis dekorator jika itu membantu.
y = someUsefulThing(...)"Pengulangan mengerikan", maka semua referensi ke semua fungsi dan metode "mengerikan". Saya gagal memahami cara menghindari referensi fungsi lebih dari sekali.
someUsefulThing(request, object_id)juga ekspresi pengambilan data. Sekarang Anda memiliki dua salinan ekspresi yang sama di berbagai titik di program Anda. Dalam jawaban yang diterima, ekspresi data ditulis satu kali. Ganti someUsefulThingpanggilan Anda dengan string yang panjang, seperti paginate(request, Post.objects.filter(deleted=False, owner=request.user).order_by('comment_count'))dan lihat kodenya. Saya harap ini akan mengilustrasikan poin saya.
Lihat wiki Python Web Frameworks .
Anda mungkin tidak membutuhkan kerangka kerja tumpukan penuh , tetapi daftar yang tersisa masih cukup panjang.
Saya sangat suka CherryPy . Berikut adalah contoh layanan web yang tenang:
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())
Ini menekankan apa yang saya sukai dari CherryPy; ini adalah contoh yang benar-benar berfungsi yang sangat dimengerti bahkan untuk seseorang yang tidak tahu kerangka kerjanya. Jika Anda menjalankan kode ini, maka Anda dapat segera melihat hasilnya di browser web Anda; mis. mengunjungi http: // localhost: 8080 / celc_to_fahr? derajat = 50 akan ditampilkan 122.0di browser web Anda.
Saya tidak melihat alasan untuk menggunakan Django hanya untuk mengekspos api REST, ada solusi yang lebih ringan dan lebih fleksibel. Django membawa banyak hal lain ke meja, yang tidak selalu dibutuhkan. Tentu tidak diperlukan jika Anda hanya ingin mengekspos beberapa kode sebagai layanan REST.
Pengalaman pribadi saya, fwiw, adalah bahwa begitu Anda memiliki kerangka kerja satu ukuran untuk semua, Anda akan mulai menggunakan ORM, plugins, dll. Hanya karena mudah, dan dalam waktu singkat Anda memiliki ketergantungan. itu sangat sulit untuk dihilangkan.
Memilih kerangka kerja web adalah keputusan yang sulit, dan saya akan menghindari memilih solusi tumpukan penuh hanya untuk mengekspos api REST.
Sekarang, jika Anda benar-benar membutuhkan / ingin menggunakan Django, maka Piston adalah kerangka kerja REST yang bagus untuk aplikasi Django.
Yang sedang berkata, CherryPy terlihat sangat bagus juga, tetapi tampaknya lebih RPC daripada REST.
Melihat sampel (saya tidak pernah menggunakannya), mungkin web.py adalah yang terbaik dan terbersih jika Anda hanya perlu ISTIRAHAT.
Berikut ini adalah diskusi dalam dokumen CherryPy tentang REST: http://docs.cherrypy.org/dev/progguide/REST.html
Secara khusus itu menyebutkan built-in dispatcher CherryPy bernama MethodDispatcher, yang memanggil metode berdasarkan pengidentifikasi HTTP-kata kerja mereka (GET, POST, dll ...).
Pada 2010, komunitas Pylons dan repoze.bfg "bergabung" untuk membuat Pyramid , kerangka kerja web yang paling banyak berbasis pada repoze.bfg. Ia mempertahankan filosofi kerangka induknya, dan dapat digunakan untuk layanan RESTful . Layak dilihat.
Piston adalah kerangka kerja yang sangat fleksibel untuk memeriksa API tenang untuk aplikasi Django.
Tampaknya semua jenis kerangka kerja web python dapat mengimplementasikan antarmuka RESTful sekarang.
Bagi Django, selain tastypie dan piston, django-rest-framework juga menjanjikan. Saya sudah memigrasi salah satu proyek saya dengan lancar.
Kerangka kerja Django REST adalah kerangka kerja REST yang ringan untuk Django, yang bertujuan untuk membuatnya mudah untuk membangun RESTful Web API yang terhubung dengan baik dan menggambarkan diri sendiri.
Contoh cepat:
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)),
)Ambil contoh dari situs resmi, semua kode di atas menyediakan api, dokumen menjelaskan sendiri (seperti layanan web berbasis sabun) dan bahkan kotak pasir untuk menguji sedikit. Sangat nyaman.
web2py menyertakan dukungan untuk dengan mudah membangun RESTful API, yang dijelaskan di sini dan di sini (video). Secara khusus, lihat parse_as_rest, yang memungkinkan Anda menentukan pola URL yang memetakan argumen permintaan ke permintaan basis data; dan smart_query, yang memungkinkan Anda untuk mengirimkan pertanyaan bahasa alami yang sewenang-wenang di URL.
Jika Anda menggunakan Django maka Anda dapat mempertimbangkan Django-tastypie sebagai alternatif untuk Django-piston . Lebih mudah mencari sumber data non-ORM daripada piston, dan memiliki dokumentasi yang bagus .
Kami sedang mengerjakan kerangka kerja untuk layanan REST yang ketat, lihat http://prestans.googlecode.com
Saat ini di awal Alpha, kami sedang menguji terhadap mod_wsgi dan Google AppEngine.
Mencari penguji dan umpan balik. Terima kasih.