Python-сообщество

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

Требуется система для публикации статей и новостей на нескольких региональных сайтах входящих в одну сеть. Так же имеется один сайт-агрегатор на котором публикуются ссылки на наиболее интересные материалы с других сайтов.
Идея у меня такая - сделать эту систему в виде SAAS, по аналогии с банерными сервисами. Разница только в том, что доступ к сервису будет осуществляться на стороне сервера на котором расположен сайт, а не на стороне браузера пользователя. Предварительно в качестве протокола связи клиента с сервером предполагаю использовать REST.

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

Cykooz
Конкретно меня пока что беспокоит только скорость работы через протокол REST

Могу успокоить. REST это не протокол, а концепция, поэтому у него нету скорости. Наверное вы все таки планируете в качестве протокола использовать HTTP 1.1 - который кстати очень из себя RESTовый (при использовании PUT, DELETE и соответствующей архитектуре).

Вообще REST это хорошо. В свое время очень помогла RESTful Web Services (2007 05) oreilly

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

Впечатление, что RESTful как и semantic web - красивые правильные концепции, но с треском провалившиеся, потому что отвечают не жизненным запросам, и абстрактным идеям.

astoon
но с треском провалившиеся

Замечательная сукцесс стори - сам HTTP построенный на RESTful принципах. Цитирую из википедии - “Самой известной системой, построенной в значительной степени по архитектуре REST, является современная Всемирная паутина.”

astoon
И никак не удается вместить в узкие рамки этой концепции все акты, что мне нужны.

Можно поподробнее - очень интересно.
Для меня одной из плюшек явилось практически автоматическое решение “одной из самых сложных” проблем программирования - инвалидация кэша, делал просто - при запросе отличном от GET, HEAD - все что выше по иерархии - инвалидируется.

astoon
Впечатление, что RESTful как и semantic web - красивые правильные концепции, но с треском провалившиеся, потому что отвечают не жизненным запросам, и абстрактным идеям.

А какая тогда достойная альтернатива? Какой либо из вариантов RPC: SOAP, XMLRPC, JSONRPC?

astoon
И похоже, не только мне, судя по тому что им не пользуются, по большому счету.

Насколько мне известно многие крупные сервисы предоставляют доступ к своему API в том числе и через REST, например Amazon S3. А судя по этой заметке http://msdn.microsoft.com/ru-ru/magazine/dd315413.aspx Microsoft склоняется к использованию REST вместо RPC.

Есть два значения этого термина - общее и частное.

Общее безуспешно, поскольку не прижилось. “Все Это делают, но никто не называет это Так.”

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

zheromo
Замечательная сукцесс стори - сам HTTP построенный на RESTful принципах.

Расхожая фраза, в которой перепутаны курица и яйцо.

zheromo
Цитирую из википедии - “Самой известной системой, построенной в значительной степени по архитектуре REST, является современная Всемирная паутина.”

Автор статьи отделался общими, не к чему не обязывающими словами.

Что имеем. То, что ожидалось - повальное использование RESTful services - этого нет. Это не нечто большое и важное, и лишь один из способов проектировать API. Один из многих. Если ваши нужны подходят под него (т.е. надо взять объект, удалить, положить, обновить) - то пожалуйста. И то не факт. Потому что потом может оказаться, что есть еще куча других команд, и как их уместить в красивую концепцию, не ясно. В итоге вы просто добавляете протокол поверх HTTP, что можно было бы сделать и изначально.

Cykooz
А какая тогда достойная альтернатива? Какой либо из вариантов RPC: SOAP, XMLRPC, JSONRPC?

Классифицировать, думаю, луше исходя из конечной цели и окружения. Из-за распостранености http удобно при проектировании сначала выбрать из трех вариантов: 1-делать поверх HTTP (дальше обычно выбор между json/xml), 2-делать не поверх HTTP (здесь дальше ветки - применять netstring или что-то другое и т.д.), 3-не важно поверх чего и как (например есть стандарты протоколов такие как EPP, распостраненые в управлении доменами - они абстрагированы от транспорта настолько, что можно даже через почту. При этом - с сессиями).

Протоколов много, и делить мир на REST и RPC, по моему, неправильно.

Такое мое мнение на данный момент, и оно может измениться.

Что же до опыта, то полезнее послушать не мой опыт, который неуспешен, а опыт zheromo, если он применил успешно.

astoon
Протоколов много…

А для каких из них есть нормальная реализация для Zope3/BB?
Для REST хотя бы есть z3c.rest.

Cykooz

astoon
Протоколов много…

А для каких из них есть нормальная реализация для Zope3/BB?
Для REST хотя бы есть z3c.rest.

Мне кажется лучше просто спроектировать внятный API так как надо, например json через http, и реализовать протокол самостоятельно. Возможно следует позаботиться об уровене абстракции, чтобы можно было добавлять и другие API (например вдруг окажется что необходимо предоставить RPC) - но это Вам лучше знать. Возможно, в BlueBream это не вызовет сильно дополнительных затрат, а даже сделает архитектуру приложения более ясной.

astoon
Суть его в том, что он использует методы HTTP, которые даже не все прижились на практике, и не известно приживутся ли вообще.

Это, так скажем, особенности реализации RESTful протокола через HTTP, совместимость достигается за счет явного указания параметра _method, добавления заголовка X-HTTP-Method-Override и т.д., и то это проявляется только в отсутствии возможности указать method отличный от GET|POST в теге form. Если мы будем взаимодействовать через AJAX или непосредственно создавать запрос сами, то никаких лишних телодвижений и не понадобится.

astoon
Потому что потом может оказаться, что есть еще куча других команд, и как их уместить в красивую концепцию, не ясно.

Это опять же попытка смешать концепции REST и RPC - REST является ресурсо-ориентированным (в отличие от RPC который настраивает мыслить в рамках некоторых действий, которых понятно может быть несколько больше чем четыре штуки, а с ресурсами НИЧЕГО кроме GET, POST, PUT и DELETE сделать то в принципе и невозможно, так что никакие другие команды не понадобятся. Естественно думать в рамках REST изначально несколько неудобно после большого опыта работы с RPC-подобными решениями.
Также не стоит забывать что у данных могут быть атрибуты и т.д., также данные очень хорошо стандартизированы (те же RFC) (в отличие от RPC, который всегда разный), и в случае REST мы всегда знаем с чем имеем дело. Это снижает объем документации и упрощает сам протокол.

Ну и как говорится лучшее враг хорошего, и то что REST мало распространен, не значит что он хуже :). И, естественно, всегда лучше выбирать подход исходя от задачи.