XWiki рассматривали, основным пользователям Bookstack показался удобнее. Мы, кстати, не стали переносить все из Confluence as is, и воспользовались поводом, чтобы навести некоторый порядок. Часть совсем технической информации, используемой только разработчиками, в результате переезжает в mkdocs, мне вообще кажется, что при настроенном CI для технических пользователей это оптимально.
Mattermost планируем в ближайшее время плотно заниматься путем добавления внешних расширений и, видимо, придется его патчить и как-то дописывать, потому что, с одной стороны, есть явные баги (например, отрицательное количество сообщений в тредах), с другой стороны функциональности групп не хватает очень. Вообще конечно при других обстоятельствах пользовались бы платной версией, но увы.
Gilab да, действительно не обладает, но пока пробуем ехать на том, что есть. Рассматривали ли Тайгу в качестве альтернативы — надо спросить, мне она заочно нравится, но опыта использования нет, т.е. момент кто что реально раньше использовал, был важен. Redmine из коробки кажется сильно проще по функционалу, понятно, что есть плагины и т.д., но видимо все-таки сразу нет.
Честно говоря, мы рассматриваем этот механизм как вариант для интранет-сети, тут таких проблем быть не должно. Собственно, по большей части этот механизм так и используется, наиболее распространенная область применения — внутренние университетские сети.
Cпасибо! Список хостеров, не планирующих переходить, повергает в уныние. По нынешним временам, конечно, надо вообще забивать на шаред и покупать всегда VPS, но не всем клиентам это можно объяснить.
Ну, в одном ресурсе может быть сколько угодно методов с различными именами и шаблонами URL, обрабатывающих GET. GET-параметры тоже никто не отменял, так что вроде как заводим соответствующие методы и вперед, если я правильно понял ваш вопрос. Cледование концепции не самоцель, собственно, в этом же синтаксисе можно описать обычный любезный всем URL-matching, просто вписав в маску HTTP сочетание GET|POST.
Из скриптовых серверных фреймворков по крайней мере RoR (см. world of resources) и web.py практически чистый REST. Не похоже, чтобы на них писали только веб-службы. Из клиентских фреймворков REST из коробки в ExtJs и Dojo как минимум, это тоже не межсерверные запросы.
Можно ли вызвать одновременно две функции за один вызов? Можно, если объединить их вызовы в новую функцию. Вроде как применимо не только к REST.
По поводу абстракции — я не предлагаю, я пользуюсь тем, что предложили более умные люди, а именно, рассматривать HTTP не как транспортный протокол, а как протокол приложения, он получается вполне достаточен для этого. Собственно меня даже в первую очередь привлекает удобная с точки зрения написания и суппорта архитектура приложения, и уже потом все остальное (stateless, которой иногда даже, о ужас, можно пожертвовать, например).
PUT и DELETE имитируются через POST одинаково практически во всех фреймворках (через _method). С точки зрения построения приложения это в любом случае не хуже, чем кодировать delete где-нибудь в URL или в POST-параметре, что, собственно, эквивалентно.
В PHP велосипедостроение — стиль жизни, увы. Что касается Kohana — оно же вроде HTTP-методы не различает, то есть там чистый матчинг адресов, или я не прав? Если прав — то это немного другой велосипед :)
Зато, кстати, описание Kohana заставило вспомнить еще один момент, который в статье не освещен, а именно — обратная генерация адресов. Вобще говоря, хорошо, когда адреса внутри приложения не прописываются явно, а единообразно генерируются, это дает возможность при необходимости малой кровью их поменять. Конечно, замена адресов конечных ресарсов маловероятна, однако, например, вынесение отдельных подкаталогов первого уровня на отдельные поддомены — запросто.
Так вот, многие фреймворки используют описание схемы не только для прямого матчинга URL → метод, но и для обратного — для генерации адресов. В нашем случае наличие сублокаторов создает проблему, так как вообще говоря, поведение сублокаторов зависит от факторов, не учитываемых в описании схемы. Есть и еще одно соображение — ссылок надо генерить много, поэтому процесс генерации должен быть максимально простым. Мы решаем эту проблему не особенно красиво — для приложения пишется примитивный класс-генератор адресов, предельно простой и не связанный со схемой приложения. Соответственно, при изменении схемы может понадобиться скорректировать и этот класс, не очень удобно, зато быстро и просто.
Просто длительное время все считали HTTP чисто транспортным протоколом, в то время как его создатели мыслили гораздо шире. А потом до всех вдруг ДОПЕРЛО :) Собственно, культа из этого делать не надо, пусть цветут все цветы, скажем REST часто противопоставляется XML-RPC и SOAP для веб-сервисов, но это специализированные решения для собственно RPC, а REST — универсален.
Что до противоречия сути HTTP — так до сих пор и с PUT и DELETE не все умеют работать по человечески, приходится имитировать через POST, со временем оно, конечно, устаканится.
Для DELETE дополнительный параметр будет в самый раз, поскольку это по сути одна операция, просто с дополнительным сайд-эффектом :) Дополнительные действия могут быть представлены как вложенный ресурс, поддерживающий операцию POST, при этом не может иметь подресурсов.
То есть, скажем, есть запись блога /entries/1231/, поддерживающая GET, PUT, DELETE. Предположим, я хочу, чтобы за запись голосовали. Создается вложенный ресурс /entries/1231/vote/, поддерживающий только метод POST, в котором и реализуется операция голосования. При этом логика сохраняется — вы действительно создаете новый голос, просто его никто снаружи не видит :) Для DELETE пример в голову не приходит — DELETE — он и в Африке DELETE :)
На эту тему можно найти много информации, например, по запросу REST design patterns есть масса всего полезного. На меня кстати в свое время произвела большое впечатление презентация автора RoR: Discovering a World Of Resources, очень хорошая, хотя система REST-диспетчеризации в RoR мне не очень нравится.
То что стандартным линком можно только GET — это правильно, стандартные линки ссылаются на различные представления. Если надо что-то другое — то это уже не линк, а форма, стилизованная под линк. К тому же если действия выполняются по GET, есть шанс, что случайно зашедший поисковик порушит всю цивилизацию :)
Прошу прощения, Ваш текст бегло глянул, может отвечу не в тему. Если диспетчеризация основывается только на основе компонент url, главный недостаток в том, что это в некотором смысле противоречит сути HTTP, в котором action — это вид запроса, а не часть URL, то есть URL определяет представление ресурса, а не действие с ним.
Соответственно, получаем более логичную, простую, а главное, стандартную схему адресов, соответствующих структуре представляемой информации, а не действиям над ней. С практической точки зрения — все компоненты приложения единообразны, не нужно придумывать сложных шаблонов адресов, структуру приложения легко формализовать, проще интегрировать приложения с внешними инструментами, например, различными JS-фреймворками.
Спасибо!
XWiki рассматривали, основным пользователям Bookstack показался удобнее. Мы, кстати, не стали переносить все из Confluence as is, и воспользовались поводом, чтобы навести некоторый порядок. Часть совсем технической информации, используемой только разработчиками, в результате переезжает в mkdocs, мне вообще кажется, что при настроенном CI для технических пользователей это оптимально.
Mattermost планируем в ближайшее время плотно заниматься путем добавления внешних расширений и, видимо, придется его патчить и как-то дописывать, потому что, с одной стороны, есть явные баги (например, отрицательное количество сообщений в тредах), с другой стороны функциональности групп не хватает очень. Вообще конечно при других обстоятельствах пользовались бы платной версией, но увы.
Gilab да, действительно не обладает, но пока пробуем ехать на том, что есть. Рассматривали ли Тайгу в качестве альтернативы — надо спросить, мне она заочно нравится, но опыта использования нет, т.е. момент кто что реально раньше использовал, был важен. Redmine из коробки кажется сильно проще по функционалу, понятно, что есть плагины и т.д., но видимо все-таки сразу нет.
и в кронтаб раз в полчаса.
И до кучи статья, как приготовить самостоятельно: meandubuntu.wordpress.com/2008/09/01/background-with-xplanet-and-xfce/
github.com/techart/tao-base/blob/master/lib/WS/REST/URI.php
класс WS.REST.URI.Template.
По поводу абстракции — я не предлагаю, я пользуюсь тем, что предложили более умные люди, а именно, рассматривать HTTP не как транспортный протокол, а как протокол приложения, он получается вполне достаточен для этого. Собственно меня даже в первую очередь привлекает удобная с точки зрения написания и суппорта архитектура приложения, и уже потом все остальное (stateless, которой иногда даже, о ужас, можно пожертвовать, например).
Зато, кстати, описание Kohana заставило вспомнить еще один момент, который в статье не освещен, а именно — обратная генерация адресов. Вобще говоря, хорошо, когда адреса внутри приложения не прописываются явно, а единообразно генерируются, это дает возможность при необходимости малой кровью их поменять. Конечно, замена адресов конечных ресарсов маловероятна, однако, например, вынесение отдельных подкаталогов первого уровня на отдельные поддомены — запросто.
Так вот, многие фреймворки используют описание схемы не только для прямого матчинга URL → метод, но и для обратного — для генерации адресов. В нашем случае наличие сублокаторов создает проблему, так как вообще говоря, поведение сублокаторов зависит от факторов, не учитываемых в описании схемы. Есть и еще одно соображение — ссылок надо генерить много, поэтому процесс генерации должен быть максимально простым. Мы решаем эту проблему не особенно красиво — для приложения пишется примитивный класс-генератор адресов, предельно простой и не связанный со схемой приложения. Соответственно, при изменении схемы может понадобиться скорректировать и этот класс, не очень удобно, зато быстро и просто.
Что до противоречия сути HTTP — так до сих пор и с PUT и DELETE не все умеют работать по человечески, приходится имитировать через POST, со временем оно, конечно, устаканится.
То есть, скажем, есть запись блога /entries/1231/, поддерживающая GET, PUT, DELETE. Предположим, я хочу, чтобы за запись голосовали. Создается вложенный ресурс /entries/1231/vote/, поддерживающий только метод POST, в котором и реализуется операция голосования. При этом логика сохраняется — вы действительно создаете новый голос, просто его никто снаружи не видит :) Для DELETE пример в голову не приходит — DELETE — он и в Африке DELETE :)
На эту тему можно найти много информации, например, по запросу REST design patterns есть масса всего полезного. На меня кстати в свое время произвела большое впечатление презентация автора RoR: Discovering a World Of Resources, очень хорошая, хотя система REST-диспетчеризации в RoR мне не очень нравится.
То что стандартным линком можно только GET — это правильно, стандартные линки ссылаются на различные представления. Если надо что-то другое — то это уже не линк, а форма, стилизованная под линк. К тому же если действия выполняются по GET, есть шанс, что случайно зашедший поисковик порушит всю цивилизацию :)
Соответственно, получаем более логичную, простую, а главное, стандартную схему адресов, соответствующих структуре представляемой информации, а не действиям над ней. С практической точки зрения — все компоненты приложения единообразны, не нужно придумывать сложных шаблонов адресов, структуру приложения легко формализовать, проще интегрировать приложения с внешними инструментами, например, различными JS-фреймворками.