Rekomendasi kerangka kerja Python REST (layanan web)? [Tutup]

321

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. :)

python web-services rest frameworks darius
sumber
Berikut tutorial yang baik tentang penggunaan web.py dreamsyssoft.com/blog/blog.php?/archives/…
Triton Man

Jawaban:

192

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.

Martin Blech
sumber
12
Ini tidak benar, Django memiliki dukungan penuh untuk mengenali POST vs GET dan membatasi pandangan hanya pada metode tertentu.
aehlke
20
Maksud saya, secara default, Django memperlakukan POST dan GET seolah-olah mereka adalah hal yang sama, yang sangat merepotkan ketika Anda melakukan layanan RESTful karena memaksa Anda untuk melakukan: jika request.method == 'GET': do_something () elif request.method == 'POST': do_something_else () web.py tidak memiliki masalah itu
Martin Blech
19
@ Wahnfrieden: Jika ada dukungan asli di Django untuk menangani kata kerja HTTP berbeda secara terpisah (dengan "asli" Maksud saya tidak perlu "jika request.method == X"), bisakah Anda mengarahkan saya ke beberapa dokumentasi?
Martin Blech
3
Penggabungan POST dan GET tidak berlaku untuk Django Class Based Views (ditambahkan pada 1.3), tapi saya percaya ini valid untuk rilis sebelumnya.
ncoghlan
1
Jawaban salah tentang CherryPy. Dari Docs: "REST (Representational State Transfer) adalah gaya arsitektur yang sangat cocok untuk implementasi di CherryPy." - docs.cherrypy.org/dev/progguide/REST.html
Derek Litz
70

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()
pengguna161642
sumber
7
Flask tidak ada di sana ketika pertanyaan diajukan ...
Martin Blech
2
Flask tidak bekerja dengan Python 3.x
bitek
3
Flask.dev sekarang mendukung Python 3
Sean Vieira
2
Flask mendukung Python 3.3 atau lebih tinggi.
mb21
3
Toh di sini, bagaimana ini tenang?
avi
23

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.

S.Lott
sumber
2
Pengulangan mengerikan d = someUsefulThing ... Bahkan orang Django menyarankan KERING.
temoto
5
@temoto: Jika y = someUsefulThing(...)"Pengulangan mengerikan", maka semua referensi ke semua fungsi dan metode "mengerikan". Saya gagal memahami cara menghindari referensi fungsi lebih dari sekali.
S.Lott
5
@temoto: "Ketika Anda perlu mengubah argumen yang diteruskan ke someUsefulThing, ada kemungkinan orang lupa melakukannya di semua panggilan"? Apa? Bagaimana itu "mengerikan"? Itu konsekuensi sepele dari merujuk fungsi lebih dari sekali. Saya gagal memahami apa yang Anda bicarakan dan bagaimana referensi fungsi "mengerikan" karena tidak bisa dihindari.
S.Lott
4
Lihat jawaban yang diterima. Ekspresi hasil {'message': 'Hello,' + name + '!'} Ditulis satu kali untuk semua presentasi.
temoto
3
Fungsi htmlView dan jsonView Anda menyajikan representasi berbeda untuk data yang sama, bukan? Begitu 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.
temoto
11

Lihat wiki Python Web Frameworks .

Anda mungkin tidak membutuhkan kerangka kerja tumpukan penuh , tetapi daftar yang tersisa masih cukup panjang.

Gimel
sumber
8

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.

Eli Courtwright
sumber
35
Itu contoh yang bagus, tapi tidak ada yang tenang tentang hal itu.
aehlke
3
@Wahnfrieden: Bisakah Anda membantu kami yang lain dengan menjelaskan mengapa Anda tidak berpikir hal di atas tenang? Dari sudut pandang saya, ini terlihat seperti contoh klasik dari REST dan tampaknya tidak melanggar aturan atau batasan dari sistem RESTful.
lilbyrdie
42
Secara sederhana, apa yang dilakukan contoh CherryPy di ​​atas adalah mengekspos metode sebagai prosedur jarak jauh "HTTP callable". Itu RPC. Ini sepenuhnya berorientasi "kata kerja". Arsitektur RESTful berfokus pada sumber daya yang dikelola oleh server dan kemudian menawarkan serangkaian operasi yang sangat terbatas pada sumber daya tersebut: khususnya, POST (buat), GET (baca), PUT (perbarui) dan HAPUS (hapus). Manipulasi sumber daya ini, khususnya mengubah keadaan mereka melalui PUT, adalah jalur utama di mana "hal-hal terjadi".
verveguy
2
Anda dapat menulis lebih banyak API RESTfull menggunakan CherryPy docs.cherrypy.org/stable/progguide/REST.html
Radian
8

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.

Savino Sguera
sumber
6

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 ...).

nir
sumber
6

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.

asthasr
sumber
Dengan Pyramid Anda dapat menggunakan Cornice , yang menyediakan bantuan yang berguna untuk membangun dan mendokumentasikan layanan web REST.
Calvin
5

Piston adalah kerangka kerja yang sangat fleksibel untuk memeriksa API tenang untuk aplikasi Django.

DenisKolodin
sumber
5

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.

Tautan: http://django-rest-framework.org/

Sun Liwen
sumber
2
Terutama antarmuka yang dapat dijelajahi menghemat banyak waktu sambil mengembangkan! Banyak keuntungan lain, jadi setiap orang yang memulai implementasi sisanya harus melihatnya. Saya mulai dengan tastypie, tetapi beralih sepenuhnya ke django-rest-framework
michel.iamit
3

Saya bukan ahli di dunia python tetapi saya telah menggunakan Django yang merupakan kerangka kerja web yang sangat baik dan dapat digunakan untuk membuat kerangka kerja yang tenang.

Jeremy B.
sumber
3

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.

Anthony
sumber
Tautan yang disebutkan tidak lagi tersedia
milovanderlinden
Tautan telah diperbarui - coba lagi.
Anthony
2

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 .

Kristian
sumber
0

Saya sangat merekomendasikan TurboGears atau Botol:

TurboGears:

  • kurang verbose dari Django
  • lebih fleksibel, kurang berorientasi HTML
  • tapi: kurang terkenal

Botol:

  • sangat cepat
  • sangat mudah dipelajari
  • tetapi: minimalis dan tidak dewasa
Federico
sumber
0

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.

Devraj
sumber