на самом деле все на месте)
методологии, возможности, фичи, расширяемость, прочее — все это не важно.
Главное — продукт должен быть и быть успешен. Его разработчики должны ясно видеть что и зачем они делают. Все остальное — вторично. Патерны и подходы, методологии и стандарты — все это не является необходимым в качественном продукте. Предусмотреть все невозможно и гонка за охватом более широкой аудитории обычно проигрывается.
Я описал построение элементарного API, реализуемого минимумом кода.
Я не говорю, что вы не правы или REST это плохо. Но некоторые его особенности плохо вкладываются в предметную область — собственно выше это уже отметили. И самая его вкусная часть — PUT/DELETE не реализуема из флеша сотоварищи.
Велосипедная авторизация у меня тоже была диктована предметной областью — мой пример вырван из SaaS системы. Естественно он является вырожденным и совсем не общим.
Предлагаю не начинать войны — мы оба правы.
login-logout — вероятно перейду на эту систему именования, спасибо.
list и прочие — это примеры команд. Данный набор команд был для простенького органайзера, list выводил список заданий и принимал в аргументах параметры выбора и прочее.
Да, патерны примерно правильно распределены. Только module — comand.
Собственно, важен не велосипед — а конечная реализация. Этот набор классов был несколько раз переписан и показал себя оптимальным с точки зрения производительности и расширяемости.
ок, дельные вопросы.
сигнатуры позволяют проверить целостность запроса+пользователями API могут быть не только люди, но и другие системы. Ни фейсбук, ни контакт в своих API не использует OAuth.
команды входят в URL — можно считать что они имеют отдельные урлы.
Не вижу особых причин делать работу API непредсказуемой — по моему неважно откуда и как пришли данные, если они правильные — на них необходимо отдать адекватный ответ.
XML легко ввести(собственно в объекте Response можно это настраивать), я просто не стал перегружать пример лишними данными.
P.S. спасибо за вашу статью, кстати, сейчас переписываю на Node.js.
методологии, возможности, фичи, расширяемость, прочее — все это не важно.
Главное — продукт должен быть и быть успешен. Его разработчики должны ясно видеть что и зачем они делают. Все остальное — вторично. Патерны и подходы, методологии и стандарты — все это не является необходимым в качественном продукте. Предусмотреть все невозможно и гонка за охватом более широкой аудитории обычно проигрывается.
Я не говорю, что вы не правы или REST это плохо. Но некоторые его особенности плохо вкладываются в предметную область — собственно выше это уже отметили. И самая его вкусная часть — PUT/DELETE не реализуема из флеша сотоварищи.
Велосипедная авторизация у меня тоже была диктована предметной областью — мой пример вырван из SaaS системы. Естественно он является вырожденным и совсем не общим.
Предлагаю не начинать войны — мы оба правы.
Просто он единственный, кто знает про объекты Module )
list и прочие — это примеры команд. Данный набор команд был для простенького органайзера, list выводил список заданий и принимал в аргументах параметры выбора и прочее.
Но производительность манит)
Собственно, важен не велосипед — а конечная реализация. Этот набор классов был несколько раз переписан и показал себя оптимальным с точки зрения производительности и расширяемости.
сигнатуры позволяют проверить целостность запроса+пользователями API могут быть не только люди, но и другие системы. Ни фейсбук, ни контакт в своих API не использует OAuth.
команды входят в URL — можно считать что они имеют отдельные урлы.
Не вижу особых причин делать работу API непредсказуемой — по моему неважно откуда и как пришли данные, если они правильные — на них необходимо отдать адекватный ответ.
XML легко ввести(собственно в объекте Response можно это настраивать), я просто не стал перегружать пример лишними данными.
P.S. спасибо за вашу статью, кстати, сейчас переписываю на Node.js.
Что у вас за задача?
мне хватило. после питона — это была пытка.
ведь без всех нас х
Хабр был бы совсем не то(р)т… )
Всем спасибо за общую идею)
да-да. именно ВАМ! )