Они правда думают, что получится спустить на тормозах свой обосрамс и сохранить лицо? Их решение о "прекращении дела" прикроет Рамблер как цветы могилу. С ним заочно уже все попрощались.
Проведя поиск по фразе «service mesh», вы наткнетесь на кучу переработанного низкокалорийного контента, странных проектов и калейдоскопа искажений, достойных эхо-камеры. Любой модной новой технологии свойственно это, но в случае service mesh проблема стоит особенно остро.
Интересно, как скоро Service Mesh настигнет судьба REST?
Этот метод работает только с оператором [] и предназначен для других вещей — создания собственных классов словарей с видоизмененной логикой d[key] без оверхеда:
>>> class Default(dict):
... def __missing__(self, key):
... return key
...
>>> '{name} was born in {country}'.format_map(Default(name='Guido'))
'Guido was born in country'
Сначала был Rust, который умел исключать ошибки при работе с памятью, но в это время группа сотрудников Microsoft обнаружила в Rust фатальный недостаток — его писали не они! Они немедленно исправили этот недочет, создав Verona, который как Rust, но другой.
The problem is that various people have described “I am using HTTP” as some sort of style in itself and then used the REST moniker for branding (or excuses) even when they haven’t the slightest idea what it means. The only way to stop people from misusing the term is to make a negative example of them when they do. https://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post#comment-996
Коротко: Никоим образом не нарушая REST, он ничем не лучше.
Во-первых, я не защищаю никакой вариант URI. Во-вторых, вас точно не смущает слово "tips" по ссылке выше? В своем гайде по именованию автор отталкивается от собственных утверждений, не ссылаясь на первоисточники. Проблема всех таких гайдов в том, что они дают противоречивую информацию, не согласуясь даже друг с другом. Один запрещает использовать глаголы в URI; второй разрешает только те, которые нельзя выразить с помощью HTTP-методов, используя для этого свои понятия, которые отсутствуют в REST. Другие же честно разделяют обязательные и необязательные ограничения. Это порождает просто чудовищную путаницу в головах, превращая REST в хреновину, которую никто не может может толком описать.
Этот вопрос выходит за рамки REST. Я не хочу показаться ханжой, но поймите одну вещь. Зацикливаясь на необязательных ограничениях по стилистике URI, мы нарушаем одно из обязательных для REST — Uniform Interface, центральной частью которого является т. н. HATEOAS (https://restfulapi.net/hateoas/). Именно грубое нарушение этого ограничения не позволяет большинству API называться RESTful, вне зависимости от того, какой стиль URI используется.
Реализация HATEOAS в API сама по себе является полноценной работой, поэтому не удивительно, что очень мало кто так делает. Да и не всем это действительно нужно, если честно. Проблема лишь в том, что мы зациклены не на тех вещах.
Чтобы долго не тошнить в комментариях, я задам несколько вопросов, а заодно кину несколько цитат от автора REST для дальнейших размышлений.
Что именно нарушают /add, /crop, /verify, /withdraw, глобальный /search в REST?
Как именно должны быть переименованы такие идентификаторы?
Кто именно создал такие требования?
A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations. http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
There is no such thing as a REST endpoint. There are resources. A countably infinite set of resources bound only by restrictions on URL length. A client can POST to a REST service to create a resource that is a GraphQL query, and then GET that resource with all benefits of REST [...] https://twitter.com/fielding/status/1052976631374000128
At no time whatsoever do the server or client software need to know or understand the meaning of a URI — they merely act as a conduit through which the creator of a resource (a human naming authority) can associate representations with the semantics identified by the URI. https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_2_4
Это очень узкая трактовка термина. Архитектура очень раннего веба (начало 1990 годов, еще до стандартизации HTTP/1.1) действительно определяла URI как идентификаторы документов, но такое определение оказалось неудовлетворительным и было отброшено. Любая адресуемая концепция вписывается в это понятие.
Чтобы не повторятся, можете прочитать https://habr.com/post/476576/#comment_20949240
Но ведь никто не говорит, что такие комментарии нарушают, например, ООП.
Никакие глаголы в URI не нарушают REST. Вопрос стиля URI это ортогональный вопрос вкуса и внутренних соглашений.
Это распространенный миф. Не существует никаких правил именования URI для REST. Все, что написано об именовании URI в этом мануале (и в других) является не больше, чем стилистической рекомендацией.
То, что метод delete и так видно, дополнительное слово не нужно и не по стандарту.
По какому стандарту?) Не бойтесь самостоятельно копнуть глубже, перед тем как открывать кому-то глаза.
Например, спецификации URI (Uniform Resource Identifiers):
A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service [...]
— RFC2396
Обновленный RFC (текущий стандарт) содержит более явную формулировку:
This specification does not limit the scope of what might be a resource; rather, the term "resource" is used in a general sense for whatever might be identified by a URI.
— RFC3986
Рой Филдинг в своем блоге дополнительно пишет о ресурсах в контексте REST:
Resources are not storage items (or, at least, they aren’t always equivalent to some storage item on the back-end). [...] Likewise, a single resource can be the equivalent of a database stored procedure, with the power to abstract state changes over any number of storage items.
— Fielding
давайте отложим в сторону холивар про то, есть или нет вообще ресурсы в REST
Они есть как таковые, но спецификации не ограничивают сферу того, что может быть отнесено к ресурсам. Многие почему-то воспринимают термин "ресурс" просто как объект данных, отсюда и миф о CRUD в REST.
Отличить REST от простого HTTP запроса невозможно. Не зная, что это REST запрос.
Потому что не существует такого понятия как REST-запрос, так же как не существует такой вещи, как RESTful URI.
Если я напишу приложение в рамках HTTP, широко используя его возможности и не нарушая его ограничений, это будет достаточным условием для того, чтобы назвать свое приложение RESTful?
Они правда думают, что получится спустить на тормозах свой обосрамс и сохранить лицо? Их решение о "прекращении дела" прикроет Рамблер как цветы могилу. С ним заочно уже все попрощались.
Аналогичная подмена понятий и девальвация термина из-за маркетингового хайпа.
https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
https://tyk.io/rest-never-crud/
https://stackoverflow.com/questions/19884295/soap-vs-rest-differences/19884975#19884975
https://www.infoq.com/articles/web-api-rest/
https://www.infoq.com/news/2016/07/microsoft-rest-api/
https://github.com/Microsoft/api-guidelines/pull/29
https://en.wikipedia.org/wiki/Talk:Representational_state_transfer
Интересно, как скоро Service Mesh настигнет судьба REST?
«Время проходит! — привыкли вы говорить по неверному пониманию. Время стоит — проходите вы.»
— Талмуд
Этот метод работает только с оператором [] и предназначен для других вещей — создания собственных классов словарей с видоизмененной логикой d[key] без оверхеда:
У встроенных словарей есть метод
__missing__который может обрабатывать промахи в словаре:https://docs.python.org/3/library/stdtypes.html?#index-51
По иронии судьбы, мем про "фатальный недостаток" обязан своим рождением Майкрософту
История программных революций от Microsoft
Сначала был Rust, который умел исключать ошибки при работе с памятью, но в это время группа сотрудников Microsoft обнаружила в Rust фатальный недостаток — его писали не они! Они немедленно исправили этот недочет, создав Verona, который как Rust, но другой.
Копнув немного глубже, вам больше не придется обсуждать это со мной)
https://developer.twitter.com/en/docs/api-reference-index.html
https://api.slack.com/methods
https://www.flickr.com/services/api/
https://vk.com/dev/methods
https://core.telegram.org/methods
Увы, не оправдан. Но перо скрипит, бумага терпит)
The problem is that various people have described “I am using HTTP” as some sort of style in itself and then used the REST moniker for branding (or excuses) even when they haven’t the slightest idea what it means. The only way to stop people from misusing the term is to make a negative example of them when they do.
https://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post#comment-996
Согласен. Какое это имеет отношение к REST?
Коротко: Никоим образом не нарушая REST, он ничем не лучше.
Во-первых, я не защищаю никакой вариант URI. Во-вторых, вас точно не смущает слово "tips" по ссылке выше? В своем гайде по именованию автор отталкивается от собственных утверждений, не ссылаясь на первоисточники. Проблема всех таких гайдов в том, что они дают противоречивую информацию, не согласуясь даже друг с другом. Один запрещает использовать глаголы в URI; второй разрешает только те, которые нельзя выразить с помощью HTTP-методов, используя для этого свои понятия, которые отсутствуют в REST. Другие же честно разделяют обязательные и необязательные ограничения. Это порождает просто чудовищную путаницу в головах, превращая REST в хреновину, которую никто не может может толком описать.
Этот вопрос выходит за рамки REST. Я не хочу показаться ханжой, но поймите одну вещь. Зацикливаясь на необязательных ограничениях по стилистике URI, мы нарушаем одно из обязательных для REST — Uniform Interface, центральной частью которого является т. н. HATEOAS (https://restfulapi.net/hateoas/). Именно грубое нарушение этого ограничения не позволяет большинству API называться RESTful, вне зависимости от того, какой стиль URI используется.
Реализация HATEOAS в API сама по себе является полноценной работой, поэтому не удивительно, что очень мало кто так делает. Да и не всем это действительно нужно, если честно. Проблема лишь в том, что мы зациклены не на тех вещах.
Чтобы долго не тошнить в комментариях, я задам несколько вопросов, а заодно кину несколько цитат от автора REST для дальнейших размышлений.
A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations.
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
There is no such thing as a REST endpoint. There are resources. A countably infinite set of resources bound only by restrictions on URL length. A client can POST to a REST service to create a resource that is a GraphQL query, and then GET that resource with all benefits of REST [...]
https://twitter.com/fielding/status/1052976631374000128
At no time whatsoever do the server or client software need to know or understand the meaning of a URI — they merely act as a conduit through which the creator of a resource (a human naming authority) can associate representations with the semantics identified by the URI.
https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_2_4
REST accomplishes this by defining a resource to be the semantics of what the author intends to identify, rather than the value corresponding to those semantics at the time the reference is created.
https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_2_1
Это очень узкая трактовка термина. Архитектура очень раннего веба (начало 1990 годов, еще до стандартизации HTTP/1.1) действительно определяла URI как идентификаторы документов, но такое определение оказалось неудовлетворительным и было отброшено. Любая адресуемая концепция вписывается в это понятие.
Чтобы не повторятся, можете прочитать https://habr.com/post/476576/#comment_20949240
Но ведь никто не говорит, что такие комментарии нарушают, например, ООП.
Никакие глаголы в URI не нарушают REST. Вопрос стиля URI это ортогональный вопрос вкуса и внутренних соглашений.
Это распространенный миф. Не существует никаких правил именования URI для REST. Все, что написано об именовании URI в этом мануале (и в других) является не больше, чем стилистической рекомендацией.
По какому стандарту?) Не бойтесь самостоятельно копнуть глубже, перед тем как открывать кому-то глаза.
Например, спецификации URI (Uniform Resource Identifiers):
A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service [...]
— RFC2396
Обновленный RFC (текущий стандарт) содержит более явную формулировку:
This specification does not limit the scope of what might be a resource; rather, the term "resource" is used in a general sense for whatever might be identified by a URI.
— RFC3986
Рой Филдинг в своем блоге дополнительно пишет о ресурсах в контексте REST:
Resources are not storage items (or, at least, they aren’t always equivalent to some storage item on the back-end). [...] Likewise, a single resource can be the equivalent of a database stored procedure, with the power to abstract state changes over any number of storage items.
— Fielding
Они есть как таковые, но спецификации не ограничивают сферу того, что может быть отнесено к ресурсам. Многие почему-то воспринимают термин "ресурс" просто как объект данных, отсюда и миф о CRUD в REST.
Потому что не существует такого понятия как REST-запрос, так же как не существует такой вещи, как RESTful URI.
Если я напишу приложение в рамках HTTP, широко используя его возможности и не нарушая его ограничений, это будет достаточным условием для того, чтобы назвать свое приложение RESTful?