REST-сервер на python3

flask?

В почти любом web-фреймворке нет ничего лишнего для сабжа.

почти в любом много чего лишнего: не особо нужен orm-layer, нафиг не нужна валидация форм, которой хвалится куча фреймворков, template-engine тоже не особенно полезен, поскольку весь вывод в json будет.

спасибо, отличный вариант

почти в любом много чего лишнего

Джанга и пирамидка это почти любые?

ещё есть http://flask-restful.readthedocs.org/en/latest/, но сказать за это ничего не могу

bottle.py еще посмотри, он еще проще.

flask(минимализм во все поля) or django + django-rest-framework(django way во все поля)

Анонимус голосует за bottle.

Глянь Tornado:

Cервер       Конфигурация               Запросов в секунду
Tornado      nginx, 4 фронтенда         8213
Tornado      1 однопоточный фронтенд    3353
Django       Apache/mod_wsgi            2223
web.py       Apache/mod_wsgi            2066
CherryPy     standalone                 785

Вариант шикарный, не из-за скорости, а скорее из-за заточенности самого фреймворка под написание RESTful API. Но не такой простой, как bottle.py или Flask.

Я использовал, спрашивайте вопросы.

не особо нужен orm-layer

Тебе не особо и уеб фрейморк пигодится тогда.

http протокол ручками реализовывать не хоцца

заточенности самого фреймворка под написание RESTful API

а в чем это проявляется?

http протокол ручками реализовывать не хоцца

wsgi есть везде.

Джанга и пирамидка это почти любые?

в определенном смысле, да

в определенном смысле, да

https://wiki.python.org/moin/WebFrameworks

Вообще, если нужно реализовать только рест с как можно более легкой оберткой, я бы взял WebOb. Плюс опционально routes.

wsgi есть везде.

в принципе, можно было бы. но лучше, если он будет обернут во что-то покрасивше. flask-restful нравится больше.

прямо gentoo-way )

нужна наиболее легкая обертка, но не в ущерб простоте использования и python-way.

спасибо за помощь, пока склоняюсь таки к flask.

прямо gentoo-way )

Да ладно, там клея будет на три десятка строк.

1. минимальная рабочая единица — не view (функция), а Handler (класс) 2. у Handler'а отдельные методы get, post, delete, etc

Пишешь базовый ResourceHandler, от него наследуешь обработчик для конкретного ресурса (FruitHandler) и все ресурсо-специфичные методы можно будет поместить в него.

from tornado.web import RequestHandler


class ResourceHandler(RequestHandler):
    resource_class = None
    resource_name = None

    def get_by_id(self, id_):
        """ Resource-specific method
        """
        return self.resource_class.collection.get(id_)

    def get(self, id_):
        """ HTTP method
        """
        r = self.get_by_id(id_)
        self.finish({self.resource_name: r})

    def create(self, data):
        """ Resource-specific method
        """
        return self.resource_class(**data)

    def put(self):
        """ HTTP method
        """
        r = self.create(self.request.arguments)
        self.finish({'success': True, self.resource_name: r})


class FruitHandler(ResourceHandler):
    resource_class = Fruit
    resource_name = 'fruit'

    def create(self, data):
        """ Create pre-sliced fruit.
        """
        return super().create(data).slice()

Казалось бы, мелочи, но это всё не в каком-нибудь отдельном пакете tornado-restful, а в ядре фреймворка. Так что продуманный дизайн и куча полезных мелочей для этого случая гарантированы.

Кроме этого, если не нравится поведение какого-то метода в RequestHandler, его можно просто один раз переопределить в своём базовом классе (например, поставить json_decode где есть тело запроса, добавить auth или просто валидацию запроса).

кстати есть всякие tapioca для такого, там правда с сопрограммами не лады но это руками правится

Tapioca is a free framework for Voice over IP and instant messaging

это что-то не то..

https://github.com/globocom/tapioca

я извиняюсь, может не очень в тему, увидел что про торнадо пишут

не-не, все в тему. лично я уже за flask взялся, но кому-то да пригодится.

вообще говоря, любой сайт нужно начинать с апи, и морду делать уже на ее основе, как клиент. при этом апи не обязан быть публичным, конечно, но это хорошая практика.

последний писк таков, что бизнес-логику делают на чем-то удобном, например рельсы или джанго, фласк по сути тот же джанго, поверх него ставится быстрый асинхронный прокси, специально для морды, который ренедрит жсоны и компилирует ассеты, кеширует ответы от ядра, таким образом оно не обязано быть слишком шустрым, в угоду удобства и скорости разработки

но это для больших систем. я лично после, скитаний по разным нодам с кофе и мета-контрол-флов надстройками типа айсед-кофе, когда вложенный код пишется последовательно, немного разочаровался нестрогостью, так сказать, языка, и вернулся к питончику. пишу на торнадо. пробовал разные библиотеки для апи, но в итоге вернулся к реквест хендлеру с хелперами типа create, update, delete для простых случаев, когда достаточно модели и формы, и кастомной логикой для сложных.

базу пока использую монгу, модели на основе schematics, легкая надстройка над словарями для описания схем структур данных и их валидации, поверх которой построить свой дбал уже не проблема. все работает очень быстро, если модель не нужна достаточно использовать словарь, нет лишних кастов. для модели описан курсор, который кастует результаты коллекции или одной модели к классу.

формы от втформ, вот и все. апи на раз-два)). но с питона3 пришлось слезть, плохая поддержка не смотря на давность, мало либ, много мороки.

ну и я как бы в среднем по хайлоаду, потому так, скорость критична

забыл сказать, все это в кучу склеивается через zope.interfaсe, zope.component, zope.event инверсию зависимостей, я пытаюсь оформить это в движок но пока нет времени, может позже выложу

для ассетов webassets, yaml конфиг бандлов, сборка для продакшна, подключение по одному для девелопмент режима, хоть туториал по торнадо пиши)))

что круто в торнадо и всяких нодах так это искаробочная вебсокетность, при должном оформлении моделей, и событийно-ориентированной архитектуре обновления пушатся по редис каналам на ура, для риалтаймовых систем, что сейчас тоже востребовано

причем в последнее время я все чаще пушу не жсон а уже готовый хтмл, со временем все эти тяжелые клиент-сайд архитектуры кажутся все более овер-компликейтед, ну события еще куда не шло на виджете, но сотни шаблонов, динамические подгрузки скриптов, это такой бред на самом деле

много интересного последнее время появляется в среде функционального программирования, я советовал бы как минимум для развития выучить как минимум ерланг, который простой как дуб, но основан на здравых идеях, но к сожалению, пока, продакш на ерланге для меня находится вне зоны комфорта, хотя фремворки типа chicagoboss выглядят здорово.

интересные разработки и про торнадо и фласк есть у mrjoes на гитхабе, там же блог на личных страницах. во-первых возможность запускать sockjs на pypy, жрет больше памяти но показывает бешенные результаты по количеству подключений. во-вторых flask-admin для скафолдинга моделей, по-моему он даже orm-agnostic, и работает как с склалхимией так и с монгоенжином.

я даже рассматриваю возможность смеси этих двух либ в гибридный движок, админку все равно нужно бы запускать в отдельном потоке, ничего не мешает делать ее синхронной. инструменты контроля апликухи должны быть консольными, ну и так далее, дерзай короче

вот еще ссылока, для общего развития http://12factor.net/, ну и очень интересное двигло pyramid, но пожалуй порог вхождения так же высок, мой торнадо-самопал по сути есть его упрощенной асинхронной версией

ну, в моем случае на мне только проектирование и реализация api. остальное свалится на кого-то еще)

да и api там.. 5-10 get'ов

// прочитал только первый и последний коммент)

ну тогда это не апи а просто 5 гетов)))

12factor тоже рекомендую, хотя это скорее не для простых приложений.

Но есть замечания: они весь конфиг предлагают хранить в переменных среды вместо файлов, объясняя это тем, что тогда конфиг никогда не попадёт в реп и что такой конфиг лучше масштабируется. Что бред, если прикинуть, что либо ты запаришься эту неструктурированную мешанину потом вспоминать при развёртывании на новом сервере, либо всё равно запишешь это в файл (для supervisord или upstart). Я считаю лучшим подход с файлами и ключами cli:

./appname --config=release.conf --debug

Ну а про сессии в memcached уже писали. Хотя бы Redis.

на счет конфига, переменные среды это бред. в переменной надо задавать только енв приложения (development/stage/production), что бы работали те же консольные утилиты. у меня это делается

$ APPNAME_ENV="development" ./starpapp

в приложении есть settings.conf и {APP_ENV}.conf дополнения

проблема с --config для меня в курице и яйце, выходит что выбор конфига определяет сам конфиг, потому появляются воркераунды и хаки, но это скорее связано с внутренней системой конфига торнадо (tornado.options), очень не хочется примешивать другое когда есть родное, и т.п.

Ну привет, сниппет с доков:

define("config", type=str, help="path to config file",
       callback=lambda path: parse_config_file(path, final=False))

именно это я и использую, но path я получаю из окружения, так удобнее, я гарантирую

потому что иначе тебе надо задефайнить опцию, получить ее, потом парсить файл из нее, такой воркераунд и предлагает документация, но идея контроля состояния через окржуения мне кажется более здравой

у меня как бы есть ./app и он сам в себе и сам знает что подгружать оглянувшись по сторонам при запуске

вообще говоря я делаю это через __main__.py и python -m appname

Плюс конфига через cli — в ps или top сервера видно, с какими параметрами запущено приложение; если не конфиг, то тот же порт или домен. Не вижу плюсов в получении конфига через окружение, если это не какой-нибудь LC_ALL и т.п.

Учитывая, что в торнадо the способ настройки приложения — это cli, странно называть workaround его, а не что-то самописное.

процессу можно задавать имя через setproctitle разные. не знаю, может я дурак, но конфиг через конфиг мне кажется не таким удобным, в конце концов методы не сильно раличаются

возвращаясь к теме апи, я использую круд хелперы, подмену метода формы в поле _method и get/post/put/delete методы requesthandler

еще, не очень в тему но есть хорошая статья https://www.facebook.com/notes/facebook-engineering/tao-the-power-of-the-grap...