Комментарии 26
кстати, кому интересно — ссылка на диссертацию Филдинга о создании REST (без регистрации и смс):
https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
Автор оригинала вольно распорядился возрастом интернета — его история началась в 1969 году, а совсем не в 1994.
Автор перевода вольно распорядился оригиналом: REST is almost as old as the web
Ответ: Потому, что ценности "Отсутствие сохранения состояния" и "Самодокументируемые сообщения" перестали быть вариантом и всё развалилось как карточный домик.
Приведите, пож, пример когда без сохранения состояния не обойтись. Если не сложно, конечно. В двух словах.
По мне так, если у приложения есть база данных, изменяемая через API этого же приложения, то у вас уже есть состояние.
Тут другое имеется в ввиду.
Нет состояния на сервере тут = клиент передаёт всю необходимую информацию для того, чтобы сервер ответил в рамках одного.
Если у тебя в бд хранится какой-то ресурс, который может меняться, но доступен по одному запросу - состояния на сервере нет.
Состояние появляется, когда на сервере нужно сохранить некий ключ перед получением этого ресура (например id пользователя) - запросы становятся зависимыми, появляется состояние (до первого запроса / после первого запроса)
Правда работать с авторизацией без состояния и секьюрно кажется довольно тяжело
Правда работать с авторизацией без состояния и секьюрно кажется довольно тяжело
А разве JWT-токены не призваны решить эту проблему? Она решается тем, что:
токен подписан и проверка его валидности + срока годности достаточно для доверительных отношений
в токен вшиты обычно все необходимые данные для авторизации действий
токен не нужно никуда "персистить". максимум - передать дальше по цепочке вызовов
Так суть не в том, что не обойтись, а в том, что игра не стоит свеч. Для тяжёлых динамических сервисов гораздо практичнее развернуть тяжёлый сессионный стейт и дропнуть его по окончании сессии со всеми ресурсами, а всё многоступенчатые запросы HATEOAS свернуть в примитивные, но локальные. Альтернатива - куки, но они тоже в немилости.
Еще раз, беда не в том, что кто-то действительно "не понимает рест", а в том, что люди осознанно его обходят. Как пример: Люди придумали GraphQL как способ взаимодействия для некоторых сценариев, но я уверен, что будут пользоваться химерой) И не потому, что "не понимают GraphQL" или что-то "нельзя выразить в GraphQL", а потому, что это неудобно и непрактично для некоторых кейсов.
Это технология, она проходит проверку временем или не проходит. Полезные идеи приживаются, терминология меняется, подходы меняются. Да сам автор тогда в 90-х вряд-ли мог вообразить во что вревратится интернет в 2020-х.
Вот эта статья, мне кажется, в подобной же риторике написана. «Вы не правильно используете». Да идите вы к чёрту, господа, как надо, так и используем.
Вот да
Иии? А что, кто-то считает как-то иначе? Как именно иначе?
Практически все, кто использует этот термин тут на Хабре, да и не только на Хабре.
Даже в комментариях под этой статьёй уже были люди, считающие что оригинальный REST имеет какое-то отношение к http-методам(get/post и пр.), хотя это не так.
Полно сервисов в интернете, которые называют свою апишку "REST"/"RESTful", но вместо реализации HATEOAS имеют спецификацию типов полей/ответов, под которую пишутся/генерируются клиенты.
Оригинальный REST по сути ближе всего к тому, как классический веб с его HTML-страничками, переходами и формами работает. Чтобы сделать сайт в простом случае, нам не нужно писать документацию/спецификацию API, вместо этого мы просто описываем наши страницы и переходы между ними через гипертекст и гиперссылки, а браузер выступает универсальным REST клиентом. И это называется HATEOAS.
p.s. Ну и да, REST Филдинга сейчас навряд ли актуален для изучения. Это просто термин который часто используют по назначению
но вместо реализации HATEOAS имеют спецификацию типов полей/ответов, под которую пишутся/генерируются клиенты.
Оригинальный REST по сути ближе всего к тому, как классический веб с его HTML-страничками, переходами и формами работает.
А как по вашему браузер понимает как правильно показывать странички, как рисовать формы и отправлять их на сервер?
Он делает это как раз за счёт "типа документа" + "спецификации для этого типа". Первое передаётся в заголовке Content-Type (в случае HTTP), а второе содержит описание того какие "поля" могут быть в документе этого типа и что с ними надо делать клиенту (или серверу).
HATEOAS предполагается использовать для изменения состояния приложения, не зашивая в клиент каждый переход между этими состояниями. HATEOAS не отменяет наличие какой-то спецификации на "тип документа", которая бы описывала в том числе и то, как найти в документе нужные клиенту ссылки. Плюс такого решения в том, что клиенту достаточно знать только "поле" в котором хранится ссылка, а сама ссылка в этом поле может меняться со временем или в зависимости от других условий. Второй механизм - наличие или отсутствие нужной ссылки в документе. Если ссылки нет - значит соответствующие "действие" не доступно для клиента. Это тоже позволяет со стороны сервера управлять поведением клиента, без необходимости зашивать в него какие-то жёсткие алгоритмы.
Но я согласен, что в большинстве случаев мало кто использует разные "типы" документов. Обычно делают один, например application/json, а как именно обрабатывать данные с таким типом в клиенте - определяют на основе каких-то зашитых в клиенте эвристик. Наверное более правильно было бы использовать разные типы данных для реально разных ресурсов. Например application/product+json, application/order+json. Но как правило это не используют, т.к., в отличии от браузера, у самописного клиента несколько больше состояний. В зависимости от текущего состояния, клиент определяет каким образом ему обрабатывать получнный от сервера application/json.
Зашитые в клиент "эвристики", вместо повсеместного использования HATEOAS, могут компенсироваться использованием REST принципа "code-on-demand". Оно позволит обновлять и дополнять код клиента, что бы он мог корректно работать после каких-то изменений на сервере.
Современные "App Store" в мобилках и десктопах - это фактически этот самый code-on-demand. Только с ними есть "проблема" - пользователи могут отключить автоматическое обновление. И если это критично для приложения, тогда надо более широко использовать HATEOAS (и даже code-on-demand) внутри самого клиента. Тогда он сможет лучше работать в условиях изменения приложения на стороне сервера. В этом плане веб-браузеры - это наиболее гибкие клиенты для распределённых клиент-серверных приложений, которые у нас сейчас имеются.
Оригинальный REST по сути ближе всего к тому, как классический веб с его HTML-страничками, переходами и формами работает. [...] описываем наши страницы и переходы между ними через гипертекст и гиперссылки, а браузер выступает универсальным REST клиентом.
REST Филдинга сейчас навряд ли актуален для изучения
Вот абсолютно согласен с этими утверждениями.
А из статьи непонятно, к какому выводу ведёт автор.
Вот абсолютно согласен с этими утверждениями.
А из статьи непонятно, к какому выводу ведёт автор.
Как по мне, основной смысл таких набросов про rest/ооп/agile etc. в том, чтобы людей подтолкнуть к более осознанному выбору подходов.
Часто за подобными баззвордами оказывается карго культ проталкиваемый не очень честными консультантами
Идея RESTful в теории звучала отлично с самого начала, только вот применительно к интернету - оказалась слишком сложна в реализации.
Браузеры договорились и внедрили методы отличные от get/post только ближе к ie7 и opera8, а это дай бог памяти годы 2008-2009? До этого момента развлекались post-методами с дополнительным полем _method=delete. Тот же html 4 поддерживал отправку форм только двумя основными методами. Так и прижилось)
Короче говора оригинальный REST не кому не был нужен или сложно реализуем... за то идея да понравилась... тоже самое говорит и про OOP
Все оказалось... зря... Ждем от автора акуальных реализаций rest. Да что там, и crud и тот видимо не тот (тоРт)? "Критикуешь, - предлагай. Предлагаешь, - действуй. Действуешь, - отвечай!"(с) А пока все работает. И поверхностных знаний и суждений явно недостаточно для модернизации существующих систем, ахитектур, паттернов и т.д.
Почему никто не понимает REST