Вы читали статью или ссылки к ней? Или комментарии? Вы уже не первый комментатор, который говорит про HTTP и подменяет это понятие на REST. Если читали, то это, наверное, я не смог передать суть подхода.

Не связывайте REST с HTTP. И никто не говорит, что это лучший подход. Но его применимость и масштабируемость доказана тем, что WWW до сих живет и процветает.

Есть и другие подходы, нужно выбирать правильный под задачу. У нас, например, и SOAP есть, и JSON-RPC и REST-based API. И каждое решение имеет под собой обоснование с плюсами и минусами.

И много вы знаете реализаций высоконагруженных систем с этим походом, особенно имея в распоряжении websocket & mq?

Посмотрите публичные API гигантов. Twitter нагруженная система?

Так это уже совсем не «тот» REST, который ресуют евангилисты REST’а. Не говоря уже о проблемах, с которыми столкнется клиент привыкший к «тому» REST’у (см. habrahabr.ru/...mpany/yandex/blog/265569 , п.п. 7,15): GET как POST, как бы нарушения рекомендаций RFC и т.п.

Яндекс пишет об HTTP, а не REST. У REST нет RFC, его первое упоминание и более менее строгое описание здесь — www.ics.uci.edu/...ation/rest_arch_style.htm.

Проблема в том, что вы не сможете за один запрос обратится к нескольким ресурсам на чтение, запись, обновление, кто знает еще чего. Это ограничено архитектурой REST.

Определение ресурса зависит полностью от вас. И да, вы можете так сделать.

The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. «today’s weather in Los Angeles»), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author’s hypertext reference must fit within the definition of a resource. A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time.

www.ics.uci.edu/...rch_style.htm#sec_5_2_1_1

неявно скатывается к тому, что REST лучший подход покрывающий все и вся. «Последние» веяния моды???

Не в коем случае не лучший подход. dou.ua/...m_campaign=comment#923251

как то все это мне напоминает ситуацию с SOAP в 2000-ых — такие же дифирамбы ему пели

Распространен не REST, а подделки в RPC-стиле на основе HTTP.

Мой ответ был близким к ответу Bogdan Shyiak.

Хотелось бы более объективный взгляд на REST. Например, рассмотреть его недостатки:

В данной статье я зациклился только на самых базовых понятиях. Размышляю уже над продолжением. Я не смотрю на REST как на панацею и на то, что его везде нужно «тулить». Я, например, слабо себе представляю как его реализовать в приложениях, которые должны работать полностью работать «оффлайн» и иногда синхронизироваться + для внутренних API в микросервисной архитектуре (микро-микро) — это может быть оверхедом. Но сейчас я работаю над приложением, где REST дает просто огромную фору, перед тем же JSON-RPC.

Что касается ссылок, которые вы привели, асинхронности, «бинарности» и не HTTP.

Я рекомендую смотреть на REST в отвязке от HTTP, он был придуман раньше и на нем построили HTTP. Это значит, что вы можете и свой протокол разработать, чтобы реализовать принципы REST. Но скорее всего этот протокол, будет почти на HTTP на 80%.

Асинхронность — это уже вопрос реализации. Например, вы можете отправить запрос на сервер и получить ответ, что он будет обработан позже. HTTP поддерживает такое поведение.

«Бинарность» — здесь хорошим примером является HTTP/2, который не отходит от REST идей, а привносит улучшения и исправления в HTTP 1.1.

З.Ы. по REST API здесь мало что описано, поэтому я бы добавил ссылку pages.apigee.com/...-design-ebook-2012-03.pdf

Эту книгу видел, я не могу ее связать прям совсем с REST API. Да там много интересных идей, но некоторые из них, мне не нравится. Гляньте ссылки к статье.

С вашим примером EC2 (docs.aws.amazon.com/.../making-api-requests.html) согласен.

Но обратите внимание, что Amazon говорит:

We provide the Query API for Amazon EC2, as well as software development kits (SDK) for Amazon Web Services (AWS) that enable you to access Amazon EC2 from your preferred programming language.

И здесь нет упоминания о REST. То что они построили свое «Query API» на базе HTTP — норм. и в этом нет ничего зазорного. Там где это REST, Amazon говорит, что это REST.

В этом как раз и фишка, что HTTP и REST не связаны. Но REST хорошо ложиться на HTTP, так как HTTP основан на нем.

JSON-RPC может работать поверх HTTP или тот же SOAP. HTTP — это протокол. REST — стиль.

Ваши примеры с S3 неинтересны, потому что S3 это уже хранилище данных, и там всё банально.

Согласен. Хорошо, оставим S3. Я вам привел пример с AppStream REST API — docs.aws.amazon.com/...e/appstream-api-rest.html.

Или что вы скажете о Twitter REST API dev.twitter.com/rest/public.

GET это чтение ресурса. Ресурс не меняется, меняется только его представление. Веб-страница представлена каждый раз по-разному.

У ресурс есть состояние и меняется оно. Представление позволяет нам узнать о состоянии. И они могут быть разными.

Ваш ответ построен на:

У программистов переменная for(i=0;i<n;i++)
У математиков ∑ i1, i2... in

Вы слишком сильно урезаете «множество» программистов, выбрасывая из него, тех кто использует функциональные/декларативные языки.

Что вы считаете востребованным и самым важным. Прошу сразу конкретики. SOAP, JSON-RPC, HTTP или свой вариант?

Для затравки — www.google.com/...p;cmpt=q&tz=Etc/GMT-3.

Интерес к RPC падает, а к REST растет. Я уже не говорю о направлении движении в разработке API от гигантов.

Никто как раз ничего и не хочет раздувать.

Если бы было так, то GET на любую страницу выдавал бы её всегда такой же

Не вижу, как это вы это связали с «WWW, который основан на REST». Может подробней расписать, пожалуйста.

Да, там есть над чем смеяться — они нарушают все принципы REST, сводя практически все запросы (включая R/O) в POST для JSON объектов. Более похабное нарушение ещё сложно себе представить.

Давайте, на конкретных примерах. Возьмем, для начала docs.aws.amazon.com/...e/appstream-api-rest.html. Одно из самых продвинутых API. Или docs.aws.amazon.com/...3/latest/API/Welcome.html. Или приведите, пример, их сервиса, где вы реально видите нарушения. Мне действительно интересно, ибо, например, AppStream API я считаю не плохим образцом.

REST — это архитектурный стиль, который ничего общего с HTTP не имеет.

Вы ж говорили, WWW «основан на REST»?

Рой Филдинг сперва описал REST в диссертации, затем участвовал в создании HTTP-протокола. REST никак не связан с HTTP. HTTP с ним связан, WWW построен на базе HTTP.

ОБРАЗЕЦ передачи состояний — и всё кагбэ попроще?

Дим, я выбрал такой перевод, который помог мне обьяснить мое понимание. Я вполне мог ошибаться и ожидание подобных комментарии — это причина появления данной статьи.

там их не так много, ШЕСТЬ, простое перечисление имхо куда лучше, чем «некоторое множество»

Я хотел заострить внимание только на базовых понятиях. Если бы я коснулся принципов, я бы слишком раздул статью. Есть идея рассказать о каждом принципе отдельно с практическими примерами.

RESTful конечно размытое, но СУЩЕСТВУЮЩЕЕ понятие

Я имел ввиду, что даже диссертация Филдинга — это всего лишь «толчок» и отправная точка. И формальной модели, мы не имеем до сих пор. ivanzuzak.info/...terminology-for-rest.html.

Там в примере не ресурс, а его представление — stateless.co/hal_specification.html, github.com/kevinswiber/siren, которое содержит дополнительную информацию, как в и в статье про Richardson Maturity Model. Ничего страшного в этом нет, но это позволяет клиент вести себя очень интересно.

Ему не нужно хранить бизнес-логику, теперь она будет в одном месте.

<appointment>
  <slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/>
  <patient id = "jsmith"/>
  <link rel = "/linkrels/appointment/cancel"
        uri = "/slots/1234/appointment"/>
  <link rel = "/linkrels/appointment/addTest"
        uri = "/slots/1234/appointment/tests"/>
  <link rel = "self"
        uri = "/slots/1234/appointment"/>
  <link rel = "/linkrels/appointment/changeTime"
        uri = "/doctors/mjones/slots?date=20100104@status=open"/>
  <link rel = "/linkrels/appointment/updateContactInfo"
        uri = "/patients/jsmith/contactInfo"/>
  <link rel = "/linkrels/help"
        uri = "/help/appointment"/>
</appointment>

Сейчас клиент может отрисовать нужные контролы или сообщения или даже не слать запрос. Представьте себе такую же реализацию, но без ссылок.

Посмейтесь над WWW, который основан на REST. Посмейтесь над Github API, Google Custom Search API, над большинством Amazon API. Посмейтесь над Twitter API.

Не смешно, правда? Вот и мы строим свои API на REST-принципах, которое действительно «МЕНЬШЕ — ЗНАЧИТ ЛУЧШЕ». Мы не дублируем логику на клиенте, а клиент у нас поверьте очень сложный. Мы не напрягаемся, когда меняются правила. Мы еще много чего упрощаем.

Не путайтест RPC over HTTP с REST. REST — это архитектурный стиль, который ничего общего с HTTP не имеет.

Вы взяли только одну из ссылок, которая совпадает с вашим представлением, а что в скажете об этих ссылках?

<appointment>
  <slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/>
  <patient id = "jsmith"/>
  <link rel = "/linkrels/appointment/cancel"
        uri = "/slots/1234/appointment"/>
  <link rel = "/linkrels/appointment/addTest"
        uri = "/slots/1234/appointment/tests"/>
  <link rel = "self"
        uri = "/slots/1234/appointment"/>
  <link rel = "/linkrels/appointment/changeTime"
        uri = "/doctors/mjones/slots?date=20100104@status=open"/>
  <link rel = "/linkrels/appointment/updateContactInfo"
        uri = "/patients/jsmith/contactInfo"/>
  <link rel = "/linkrels/help"
        uri = "/help/appointment"/>
</appointment>

Как вы понимаете первый пункт? Можно не цитировать. Я увидел там речь об HTTP-методах. Это никакого отношения к REST не имеет, как и формат URI.

Самое не приятное здесь, то что Яндекс может навязывать заблуждения. Почитайте комментарии к той статье.

Я вас прошу полистать ссылки, которые я указал под статьей. Иначе мы, просто стоим, на месте.

Мне кажется, что я понимаю вашу точку зрения, так как и сам раньше так думал. Но это не совсем то о чем я писал в статье. Мне кажется, что вы сильно привязаны к HTTP-методам и ограничены CRUD. Вы пытаетесь строить CRUD над любым ресурсом, будь-то действие копирование или создание чего-либо.

Верите или нет, но HTTP — это просто протокол и никак не связан с архитектурным стилем REST, кроме того, что проектировался на его идеях.

Пройдитесь, по ссылкам, пожалуйста.

Я не против этого и поддерживаю вас в данном случае. Я лишь говорю о том, что URI не имеет значения + добавляю возможность получить список действий. Как в вашем случае узнать, что операция копирования не доступна для ресурса? Послать OPTIONS запрос? И вы получите пустой список методов.

В моем случае, вы получаете представление ресурса + ссылки на возможные действия с ним.

Все же рекомендую прочитать часть диссертации и хотя бы martinfowler.com/...hardsonMaturityModel.html. Если еще и по ссылкам пройдетесь, которые кинул, то у нас появиться взаимопонимание.

если можно обойтись только GET и POST,

Методы остаются. Мы используем PUT для create or update, DELETE для удаления, OPTIONS для получения методов. Но клиент не делает запрос OPTIONS, клиент, который пишет разработчик руками заведомо знает, что ему нужно послать запрос POST по определенной ссылке и знает медиа-тип содержимого, которое нужно послать. Есть у нас приложение в браузере — это наш клиент, а вот сам браузер уже выполняет OPTIONS-запрос, например, для получения CORS-заголовков — fetch.spec.whatwg.org/#preflight-request.

это получается тот же самый RPC

Я бы сказал так, RPC — это когда вы используете URL и HTTP-методы для вызова метода над ресурсом, а тело запроса как параметры.

POST и GET — это не совсем те действия о которых идет речь. Ресурсом может быть и само действие.

Давайте попробуем на вашем подходе смоделировать пару кейсов. Например, у нас есть Google Slides и мы делаем для него API. Приведите примеры, как бы вы реализовали копирование слайда, сортировку слайдов, как бы их заблокировали для редактирования.

с ресурсом ограничен простыми HTTP методами (GET, POST, PUT, PATCH, DELETE)

Смоделируйте сортировку ресурсов, копирование, активацию/деактивацию ресурса и т. д.

Я всё удивляюсь примеру про счёт в банке, который копируют с википедии.

Я этот пример выбираю нарочно, так как идеально описывает HATEOAS.

Синтаксис и формат URI, вообще, не имеет значения. Это просто идентификатор и если он будет такой /accounts-1-close и ведет на ресурс, который «закрывает счет» (это скорее всего тоже транзакция будет), то это не нарушает никаких правил и принципов. Это одна из самых важный вещей про URI — это просто единообразный идентификатор ресурса, что внутри — не имеет значения. Про URI рекомендую — .

Я конечно не читал диссертацию Роя, и возможно в ней нет ничего про то что URI (в данном примере URL) должен указывать на ресурс, а не на действие.

Рекомендую почитать, она написана общедоступным языком и часть про REST очень короткая. Протокол HTTP Филдинг проектировал уже на основе REST принципов. Процитирую еще раз ту часть диссертации, которую указал в статье, об определение ресурса:

The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. «today’s weather in Los Angeles»), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author’s hypertext reference must fit within the definition of a resource. A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time.

Ресурс — это не обязательно сущность, это может быть набор сущностей, а может быть сервис. Это абстракция.

В то время как перечень операций с ресурсом ограничен простыми HTTP методами (GET, POST, PUT, PATCH, DELETE), и этот список можно узнать сделав запрос OPTION для ресурса.

HTTP-методы — это действительно в каком-то роде операции над ресурсом и про OPTIONS вы правы. Но URI и HTTP-методы имеют опосредованное отношение к действию над ресурсами.

Самое важное — это представления, именно, они меняют состояние ресурса. Скорее всего, для /accounts/1/close — это был бы POST-запрос, например, с причиной закрытия счета.

Это одно из самых частых заблужлений, что REST представляют как CRUD. В статье добавлял ссылку — www.thoughtworks.com/...-design-resource-modeling, где очень наглядно показывается как моделировать ресурсы.

Не думайте об HTTP, когда говорите о REST. Представьте себе реализацию без HTTP. HTTP-методы нам не нужны, они просто добавляют дополнительные фишки — идемпотентность и т. п. Представьте себе какой-нибудь текстовый протокол или бинарный, не суть важно, и представьте, что вам нужно как-то менять состояние ресурса, читать его и видеть список возможных действий + пара ограничений (коммуникация без состояния и без сессии клиента).

Вам понадобятся идентификаторы ресурсов, их представления и формат гиперссылок на действия.

Мы используем SOAP, претензий к нему не имею. Каждый инструмент хорош для своих целей.

Про велосипед — я имею ввиду, какие-то «свои» реализации REST.

Слово «состояние» — можно отнести к слову паразиту. И в REST оно много где есть, как и в самом названии.

«Representational state transfer», я в это статье пытался быть ближе к названию и к самим азам.

Обратиие внимание, на эту часть www.ics.uci.edu/...rch_style.htm#sec_5_2_1_2. Статью я, практически, полностью посвятил ей.

То что о чем вы говорите, всего лишь один из принципов REST и его можно применить и при RPC-подходе.

Хорошее замечание, спасибо!

Правда, не знаю, почему вы сделали акцент именно на этой части диссертации Филдинга, но если пойти все же к части о ресурсах и их представлениям, то:

REST components perform actions on a resource by using a representation to capture the current or intended state of that resource and transferring that representation between components.

Действительно, самое главное, что я пытался донести — это то, что состояние приложения и есть совокупность состояний ресурсов и мы эти состояния можем изменять. Я даже близко не подошел к теме о состоянии клиента и нигде об этом не упоминал в статье, кроме комментариев — dou.ua/...s/rest-conception/#921402. Считаю, что это тянет на отдельную статью и желательно с практическими примерами.