Чи є десь список рекомендацій різних каркасів REST на основі Python для використання на сервері для написання власних API RESTful? Переважно з плюсами і мінусами.
Будь ласка, не соромтесь додавати сюди рекомендації. :)
Відповіді:
Що потрібно бути обережним при розробці API RESTful - це співвідношення GET і POST, як ніби вони однакові. Це легко зробити цю помилку з Django «s функції на основі поглядів і CherryPy » по замовчуванням диспетчера s, хоча обидві структури в даний час забезпечує спосіб обійти цю проблему ( погляди на основі класів і MethodDispatcher , відповідно).
HTTP-дієслова дуже важливі в REST, і якщо ви не будете дуже обережні, ви потрапите в анти-шаблон REST .
Деякі рамки, які підходять правильно, це web.py , колба та пляшка . У поєднанні з бібліотекою мімеренда (повне розкриття: я це написав) вони дозволяють писати приємні RESTful веб-сервіси:
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()Логіка служби реалізується лише один раз, і правильний вибір представлення (Прийняти заголовок) + відправка до належної функції візуалізації (або шаблону) здійснюється акуратно, прозоро.
$ 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 р.) : Додана інформація про класичні погляди Django, CherryPy's MethodDispatcher та фрейми та пляшки. Жодного разу не існувало, коли було задано питання.
Здивований, що колбу ніхто не згадав .
from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello():
return "Hello World!"
if __name__ == "__main__":
app.run()Ми використовуємо Django для RESTful веб-сервісів.
Зауважте, що - поза межами Джанго не було достатньо тонкої аутентифікації для наших потреб. Ми використовували інтерфейс Django-REST , який дуже допоміг. [Ми з тих пір розгорнули свою власну, тому що ми зробили так багато розширень, що це стало кошмаром технічного обслуговування.]
У нас є два види URL-адрес: "html" URL-адреси, які реалізують орієнтовані на людину HTML-сторінки, та "json" URL-адреси, що реалізують обробку, орієнтовану на веб-сервіси. Наші функції зору часто виглядають так.
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, тому зробіть їх частиною класу, за яким можна телефонувати, або напишіть декораторів, якщо це допоможе.
y = someUsefulThing(...)це "жахливе повторення", то всі посилання на всі функції та методи "жахливі". Я не розумію, як уникнути посилання на функцію не один раз.
someUsefulThing(request, object_id)само вираження пошуку даних. Тепер у вас є дві копії одного виразу в різних точках вашої програми. У прийнятій відповіді вираз даних записується один раз. Замініть свій someUsefulThingдзвінок на довгий рядок, наприклад, paginate(request, Post.objects.filter(deleted=False, owner=request.user).order_by('comment_count'))і подивіться на код. Сподіваюся, це проілюструє мою точку зору.
Див . Вікі веб-рамок Python .
Вам, напевно, не потрібні рамки повного стека , але список, що залишився, все ще досить довгий.
Мені дуже подобається CherryPy . Ось приклад спокійного веб-сервісу:
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? градусів = 50 відобразиться 122.0у вашому веб-браузері.
Я не бачу жодних причин використовувати Django просто для викриття api REST, є більш легкі та гнучкі рішення. Джанго несе на стіл багато інших речей, які не завжди потрібні. Напевно, це не потрібно, якщо ви хочете виставити якийсь код як послугу REST.
Мій особистий досвід, fwiw, полягає в тому, що як тільки ви матимете фреймворк одного розміру, ви почнете використовувати його ORM, його плагіни і т. Д. Просто тому, що це легко, і за короткий час у вас не виникне залежність. цього дуже важко позбутися.
Вибір веб-рамки - це важке рішення, і я б уникнув вибору рішення для повного стека лише для того, щоб виставити RI-версію api.
Тепер, якщо вам дійсно потрібно / хочете використовувати Django, то Piston - це приємна рамка REST для додатків django.
Як сказано, CherryPy також виглядає дуже приємно, але здається більше RPC, ніж REST.
Дивлячись на зразки (я ніколи цього не використовував), напевно, web.py - найкращий і найчистіший, якщо вам потрібен лише REST.
Ось дискусія в документах CherryPy на REST: http://docs.cherrypy.org/dev/progguide/REST.html
Зокрема, він згадує про вбудований диспетчер CherryPy під назвою MethodDispatcher, який викликає методи, засновані на їхніх ідентифікаторах HTTP-дієслів (GET, POST тощо).
У 2010 році спільноти Pylons та repoze.bfg "об'єднали сили", щоб створити Pyramid , веб-структуру, яка найбільше базується на repoze.bfg. Він зберігає філософії своїх батьківських рамок і може використовуватися для RESTful послуг . Це варто подивитися.
Поршень - це дуже гнучка рамка для управління інтерфейсами API RESTful для додатків Django.
Здається, всі види веб-рамок python зараз можуть реалізовувати інтерфейси RESTful.
Для Django, окрім tastypie та поршня, багатообіцяючим є згадка про django-rest-frame. Я вже безперечно мігрував один із своїх проектів.
Рамка Django REST - це легка рамка REST для Django, яка має на меті полегшити побудову добре пов'язаних, самоописуючих RESTful веб-API.
Короткий приклад:
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)),
)Візьмемо приклад з офіційного сайту, всі наведені вище коди містять api, документ, що роз'яснюється (наприклад, веб-сервіс на основі мила) і навіть пісочницю, щоб трохи перевірити Дуже зручність.
Посилання: http://django-rest-framework.org/
Я не є експертом у світі пітонів, але використовую django, який є чудовою веб-базою та може бути використаний для створення спокійної структури.
web2py включає підтримку легко створювати API RESTful, описаний тут і тут (відео). Зокрема, подивіться parse_as_rest, що дозволяє визначати шаблони URL-адрес, які відображають аргументи запиту до запитів бази даних; і smart_query, що дозволяє передавати довільні запити на природній мові в URL.
Якщо ви використовуєте Django, то ви можете розглядати django-tastypie як альтернативу django-поршень . Легше налаштовуватися на джерела даних, що не належать до ORM, ніж на поршень, і має чудову документацію .
Ми працюємо над основою для суворих REST-послуг, перегляньте http://prestans.googlecode.com
Наразі це є на початку Alpha, ми протестуємо на модулі mod_wsgi та Google AppEngine.
Шукаєте тестерів та відгуки. Дякую.