Comments 22
Это опасный путь. Мнение одного авторитета-практика против мнения одного авторитета-теоретика. При этом доподлинно неизвестно как сам авторитет-практик относится к данному конкретному авторитету-теоретику. Таким способом можно разделать любую идею самого авторитетного теоретика. Но чаще под этим лежит чисто практическая сметка. Ибо. Разделить авторитетов-теоретиков на стратосферных и просто высоких можно 2^N способами.
Нет, нет, нет.
Основное достоинство rest api по сравнению с rpc over http — он понятнее и позволяет использование огромного количества клиентов — от curl и браузера до python/java/c++
Если ваш рест апи непонятнее рпц или несовместим с чем-то из вышеперечисленного — никому он такой не нужен.
Пост о том что RESTAPI в привычном нам формате, например как это преподносится на ресурсе http://www.restapitutorial.ru/ ничем не отличается от RPC
Если быть честным, этот сайт описывает все ограничения REST, только расставляет неправильные акценты. К слову, на странице Resource Naming (рекомендации по именованию URI, с которых все начинают и на них же останавливаются) честно сказано, что "This is not a REST rule or constraint, but it enhances the API." Если это не rule и не constraint, тогда что ими является? Мало кто задается такими вопросами, поэтому имеем то, что имеем.
Нужно признать, что хотел автор или не хотел, но аббревиатура REST[Full]API обрела свою индивидуальную жизнь. По части различных попыток оформить правила REST[Full]API в виде некоторого свода best practics меня смущают две вещи. 1) То что все они начинают с принципов REST — которые тут же и нарушают, и 2) что эти правила будучи использованы в проектах сложнее, чем TODOAPP покрывают 0,01% случаев, так как все интересное начинается когда мы переходим от плоских объектов к объектам со связями — а их у нас большинство в задачах даже самых простых но реальных.
Автор просит убрать префикс REST в словах REST API, RESTFull API а также не применять к ним аббревиатуру HATEOAS, чтобы не ронять свой научный авторитет.
Нужно убрать потому что так требует автор архитектуры REST. По его (и не только его) мнению он разработал архитектуру приложений, которая должна быть лишена тех проблем с которыми ежедневно сталкиваются разработчики REST API. То что системы якобы построенные на предложенных им принципах имеют такие проблемы ставит под сомнение ценность этой архитектуры. Поэтому автор и пытается отмежеваться от своих не к месту рьяных лже-последователей.
Это примерно как сказать, что какой-то паттерн проектирования не имеет стандарта, поэтому никто не вправе ограничивать нас в его трактовке. Так любая терминология может потерять смысловую нагрузку. Почему мы вообще даем имена вещам?
Почему мы вообще даем имена вещам?
Не "почему", а "зачем". Чтобы легче было говорить о них. Удачность термина — определяется успешностью коммуникации с его использованием. Если термин утратил первоначальный смысл и приобрёл новый — ничего с этим не поделаешь. Как-то бороться можно только пока отклонения статистически редки.
В отличии от автора REST я сильно не переживаю о том что REST[Full]API использует в себе аббревиатуру архитектуры которую оно фактически в большинстве случаев не реализует.
Мне немного досаждает тот факт, что в tutorials и best practics по REST[Full]API 70% текста идет пересказ основных принципов REST архитектуры (как она определена автором архитектуры REST), а потом предлагается делать нечто совершенно противоположное этой архитектуре.
Такой софистикой можно оправдать любой распространенный миф. У нас будут проблемы с устойчивым определением того, какой именно смысл приобрел REST. Предлагаю вам ответить на простой вопрос: RESTful API — это API, который что?
Это не софистика, а голый принцип действия коммуникативной системы.
Если бы этим можно было "оправдать любой распространённый миф" — у нас были бы проблемы с определением каждого имеющегося в нашем языке слова. Но это, очевидно, не так.
RESTful API — это API, который что?
Не знаю. Мне пока не случалось о нём говорить. А когда понадобится — я буду понимать под этим то же самое, что наибольшее количество моих собеседников, иначе сам окажусь не понятым.
Если почитать выброс на Хабре за эту неделю по тематике RESTAPI — ни один из авторов не называет этот подход удобным. То есть он удобный, но почему-то с ним приходится преодолевать некие трудности.
2 раза прочитал, так и не понял — почему этому надо следовать? Потому, что именно вам так удобнее?
Этому не нужно следовать. Это описание архитектуры которая называется REST.
Вы либо ей следуете, либо нет, и в этом нет ничего плохого.
Проблема которую Рой Филдинг(он автор обсуждаемого термина) затрагивал уже много раз заключается в том что люди называют аббревиатурой «REST» архитектуры которые на самом деле таковыми не являются, и не соблюдают требования описанные в т.ч. в этой статье.
В целом REST и вводимый набор ограничений описан изначально в оригинальной документации — www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf
REST API должен основываться на гипертексте