Релокейт-опрос 2017 (для тех, кто уже уехал). Собрано более 1500 анкет.
×Закрыть

Синхронизируем понимание REST

Цель данной статьи — уменьшить объем заблуждений и синхронизировать понимание основных принципов REST с сообществом.

REST и WWW

Можно сколько угодно говорить о преимуществах и недостатках текущей архитектуры WWW, но ее применимость, устойчивость к развитию и работоспособность доказана годами практического применения. Этим Рой Филдинг и воспользовался. Он предложил использовать Web не только для общения между человеком и машиной, но и для общения между машинами.

Примерно, преобразовав это:

<div class="account">
	<div class="identifier">12345</div>
	<div class="balance">500</div>
</div>

В это:

{
	"account": {
		"identifier": "12345", 
		"balance": 500
	}
}

REST задуман так, что если правильно применять, то можно построить приложение (с API), которое будет работать и масштабироваться веками.

Архитектурный стиль

Я очень люблю названия и аббревиатуры в IT. Я уверен, что правильные названия в разработке — это уже 80% успеха.

REST — REpresentational State Transfer. Я перевожу это так — передача/изменения состояния через представления. REST — это архитектурный стиль, некоторое множество ограничений, для построения распределенных приложений. Здесь нет ни слова об API, HTTP или красивых URL.

Если бы меня спросили, что нужно запомнить про 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»

— Roy Fielding’s dissertation

Ключевое понятие в REST — это ресурс. Ресурс имеет состояние, и мы можем его получать или изменять при помощи представлений. Наше приложение отвечает за некоторое множество таких ресурсов. Кстати, совокупное состояние ресурсов — это и есть состояние приложения.

Под представлением можно понимать JSON/HTML/XML/текст в определенном формате или что угодно, что позволяет нам понимать состояние ресурса или его модифицировать. Достаточно помнить, что REST про общение между машинами.

Представление, которое модифицирует состояние ресурса, и представление, которое что-то говорит нам о состоянии, не обязательно должны друг другу соответствовать.

Единообразные идентификаторы ресурсов — URI

Плавно подходим к практической стороне вопроса. Мы понимаем, что состояние нашего приложения — это состояние ресурсов, за которые отвечает приложение, и мы знаем, что мы можем изменять его через представления (ресурсов).

Как нам изменить состояние конкретного ресурса? Как найти этот конкретный ресурс? Для это и придуманы URI, чтобы идентифицировать ресурсы.

Об URI лучше всего думать как об имени или псевдониме ресурса. U — это unified, а не unique. Имен у одного и того же ресурса может быть много. Главное, чтобы они были понятными для машин. Например, «bank.account.1» и «bank.accs.first» могут быть вполне реальными идентификаторами в определенной системе.

URL — это самый известный стандарт для идентификации ресурсов в интернете. URL — это частный случай URI, конкретная реализация.

HATEOAS

Мы понимаем, что такое состояние ресурсов, можем идентифицировать ресурсы, знаем, что можем менять состояние через представления. Эти понятия не меняют правила игры принципиально и не предлагают чего-то, что позволит нам взойти на новый уровень разработки распределенных приложений.

А вот Hypermedia as the Engine of Application State всё меняет, и эта концепция в REST мне нравится больше всего. Я бы сказал, что это одно из ключевых понятий REST, которое действительно отличает REST от других сетевых архитектур.

Давайте предоставим клиенту возможность понимать, в какое состояние он может перевести ресурс, и как он может получить эти состояния:

<?xml version="1.0"?>
<account>
   <accountIdentifier>12345</accountIdentifier>
   <balance currency="USD">100.00</balance>
   <link rel="deposit" href="http://somebank.org/account/12345/deposit" />
   <link rel="withdraw" href="http://somebank.org/account/12345/withdraw" /> 
   <link rel="transfer" href="http://somebank.org/account/12345/transfer" />
   <link rel="close" href="http://somebank.org/account/12345/close" />
 </account>

Это состояние представление счета в банке от сервера, которое содержит ссылки на действия, которые можно совершить со счетом. Например, на счет можно пополнить или закрыть.

В данном случае действия, которые можно произвести над счетом, вычислил сервер. Обратите внимание, что клиенту не нужно содержать логики для вычисления возможных операций и ему не нужно знать URL операции. Это сильно «развязывает руки» серверу. Например, в начале мы разрешали снимать деньги со счета, только если баланс положительный, а что если мы потом позволить уходить в минус?

Есть еще некоторые неочевидные преимущества. Например, у вас есть меню ресторана, в нем есть перечень блюд и цен. Вы можете отдавать представление меню только с именованием блюд и в этом же меню ссылаться на цены. Тогда представление с наименованиями можно закэшировать надолго, а цены закэшировать в соответствии с частотой их изменения.

Самое важное здесь, что клиент знает только одну точку входа, только один URL. А дальше он получает представления и видит набор возможных действия, и он может принимать уже соответствующие решения. Это в разы может упростить клиент, так как ему не нужно хранить логики, а он может полностью опираться на ссылки. И, кстати, да нет такого понятия, как красивые URL (может, только в SEO), ваш клиент полностью отвязан от URL, и вы вольны именовать их как угодно. Да, хоть преобразуйте в Base64, если вам так удобно.

Моделирование ресурсов

Одна из самых тонких тем в REST — это моделирование ресурсов. Здесь не существует какого-то единого подхода или простого правила, которое вам поможет точно подобрать границы ресурса. Старайтесь проектировать API так, чтобы оно не могло привести приложение в неработоспособный вид.

Например, вы пишете API для управления блогом. Если у вас есть требование, что к каждой статье обязательно должны быть указаны тэги, то вам необходимо спроектировать API так, чтобы клиент не смог нарушить этого свойства. Как вариант, при запросе на создание статьи необходимо дополнительно передать список тэгов.

А как бы вы реализовали операцию изменения состояния счета? Верно, через транзакции. Транзакция на пополнение счета, транзакция на перевод средств и т.д.

Моделирование ресурсов также не просто, как и моделирование предметной области.

Стандарты

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

Но существует множество маленьких стандартов, которые дополняют данный стиль со стороны:
— URI и URI Template — об единообразных идентификаторах ресурсов;
— HTTP — как протокол передачи «гипертекста»;
— HAL, Siren — для реализация HATEOAS;
— JSON, XML и «семья» могут использоваться для представлений;
— HTML можно использовать не только для представлений, но и черпать из него идеи для гипермедиа компонент.

Готовые решения

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

И есть еще кое-что, это HATEOAS, и здесь индустрия не стоит на месте. Есть библиотеки, которые упрощают работу с построением ссылок в разы.

Если вы программируете с использованием Java, то обратите внимание на Spring HATEOAS. Если вашим основным языком разработки является PHP, то могу порекомендовать Hateoas.

Практические примеры

Сейчас можно заметить все больше и больше примеров API, которые применяют REST-принципы. Я приведу те, которые мне нравятся больше всего. Будет здорово, если вы дополните в комментариях.

Github API. Github очень широко применяет гиперссылки, например тут. Их API отображает ссылки даже в том случае, если какое-либо действие не доступно пользователю.

Amazon AppStream API. Данный API использует HAL. Это хороший пример HATEOAS, так как наличие ссылок определяет состояние приложения и позволяет его переводить в другое состояние.

Twitter REST API. Может показаться, что у Twitter-a не REST API, но это из-за огромного количества URI-шаблонов.

Wurl API. Есть и более продвинутые примеры. В данном случае, компания использует вышеупомянутый Siren. Например, можно следить за сериями, отправив POST-запрос с определенными параметрами.

Источники информации и полезные ресурсы

Список ресурсов, с которых я черпал информацию и которые могут показаться вам полезными:
— Публичные API, использующие HAL;
— Формат HAL;
— A list of libraries for working with HAL (Obj-C, Ruby, JS, PHP, C#, etc.);
— Часть диссертации Роя Филдинга о REST;
— От CRUD к hypermedia API с использованием Spring;.
— Моделирование ресурсов в REST;
— «REST: Я думаю, что это означает то, что вы думаете, что оно делает»;
— REST in Practice: Hypermedia and Systems Architecture
— Siren;
— HAL browser;
— Building a Hypermedia-Driven RESTful Web Service.

86 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

позавчера ехал с работы и думал об одном паттерне, который можно завязать на ресте и пришел к мысли, что рест не всегда самый лучший вариант для новых проектов, а потом и вовсе подумал, что рест это не так уж и хорошо.
и мне даже стало жаль один проект, который делал рестом. захотелось переписать)
читал раньше этот доклад 2000го года и как-то там нашел несколько противоречий.
РЕСТ должен быть стейлес но что касается авторизации советуют делать токеную реализацию и гонять этот токен в каждом реквесты или кешировать редисом как альтернативный вариант.. у меня просто возник вопрос, а почему не можно тогда открыть обычную сессию или использовать куки ведь это вполне реально же даже в рестовом проекте. это «не можно» вот не больше чем желания не делать, потому что вот если так сделает оно, поломает какую-то логику, которой физически даже не существует.
точнее логику о том, что теперь якобы сервер будет иметь представления об клиенте и держать в себе какую-то логику, что по рестовой архитектуре не должно быть. Но на самом то, блин, деле оно же ничего не изменяет в роботе того самого АПИ!
потому, что даже у этой крутой токеной авторизации есть ну очень много несекюрных косяков.
Вообщем.. такие дела.

позавчера ехал с работы и думал об одном паттерне, который можно зав«язать на ресте и пришел к мысли
Но название паттерна вы никому не скажете? :)
Судя по потоку сознания, вы могли иметь ввиду JWT. Если да, то сюрприз: REST не требует использования JWT.
РЕСТ должен быть стейлес но что касается авторизации советуют делать токеную реализацию и гонять этот токен в каждом реквесты или кешировать редисом как альтернативный вариант..
А можно подробнее, как вы узнаете какой токен доставать из кеша? Токен — это ключ по которому получаются данные (в случае с JWT полчаются из самого токена)
у меня просто возник вопрос, а почему не можно тогда открыть обычную сессию или использовать куки ведь это вполне реально же даже в рестовом проекте.
Куки использовать можно, если делать это правильно. Пересказывать все нюансы работы с куками долго, поэтому просто напомню что куки — это по сути своей хидер.
С сессией похожая проблема, есть большая вероятность что вы ее будете использовать не правильно. А если ее использовать правильно, то вариант с редисом может быть попросту проще в реализации :)
это «не можно» вот не больше чем желания не делать, потому что вот если так сделает оно, поломает какую-то логику, которой физически даже не существует.
Пожалуйста, расскажите поподробнее и попонятнее.

оо, я учту ваши поправки на счет jwt и куки.
спасибо)
и раз уж на это пошло, то какие примеры токеной авторизации можно использовать вместо jwt но при это, чтобы spring security к примеру, мог понимать роли..?
Дня 4 провозился с этой проблемой, в конце сделал через jwt, а роль просто передаю в токене, а на фронте ее вытаскивают и роутят. но в моей конфиге спринг сек, интерцептеры работают только на .permitAll или .deniedAll.
или если говорить об авторизации через соц сети и рест тогда более менее понятно. хотя тоже запутано нужно ли для разных сетей, разные поля под их токены?

За що я люблю доу: статтю читаєш 5хв, а потім годину розбираєшся хто ж все-таки правий в коментарях :) Дякую за статтю, вона точно користа, тим більше людям, які вцілому намагаються зрозуміти що таке REST і що таке REST API.

Еще интересный пример — developer.paypal.com/...st-payment-hateoas-links.

REST, конечно, хорош, но вот только есть ряд вопросов:
1. как осбтаят дела с асинхронными вызовами?
2. куда будет ложится REST, если архитектура далека от CRUD и GET/POST/DELETE/PUT/PATCH недостаточно?
3. что делать, если для чтения необходимо передать сложный объект/массив обектов?
4. что делать, если надо «ложиться» не на HTTP?
5. что делать, если необходимо выполнять пакетную обработку?

Хотелось бы более объективный взгляд на REST. Например, рассмотреть его недостатки:
www.programmableweb.com/...tives/analysis/2013/12/19
www.programmableweb.com/...keeps-me-night/2012/05/15

По мне, так, рест имеет смысл использовать, если вы хоите предоставить публичный API и кэшировать GET запросы (и то не всегда, например, HTTPS). Больше я не вижу никаких преимуществ в нем.

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

По мне, так, рест имеет смысл использовать, если вы хоите предоставить публичный API и кэшировать GET запросы

Дане твердження вже вдруге згадується в цій темі і вдруге — від тих, хто пише на Java. Це ж очевидно, що є ніші (і немаленькі), де REST себе виправдовує більш ніж, тому приміряти його не себе — справа невдячна. Мене більше цікавить, що ви можете протиставити у відповідь?

как осбтаят дела с асинхронными вызовами?
Я б не змішував конкретну реалізацію на конкретній мові програмування з такими фундаментальними речима, як REST. Спочатку ми будуємо REST, а вже потім в ньому самому ідуть самі асинхронні запити.

Якщо помиляюсь, прошу мене виправити.

Дане твердження вже вдруге згадується в цій темі і вдруге — від тих, хто пише на Java.
У вас какой-то пунктик к Java/JVM?
Це ж очевидно, що є ніші (і немаленькі), де REST себе виправдовує більш ніж, тому приміряти його не себе — справа невдячна.
Никто же не спорит с этим. Вопрос к статье, от прочтения котрой слаживается впечетление, что REST покрывает “все и вся”.
Мене більше цікавить, що ви можете протиставити у відповідь?
Скорей всего вы не поняли суть моего поста:
Хотелось бы более объективный взгляд на REST.
А если уж сильно хочется посмотреть алтернативы, то гугл в помощь: mixlip.ru/...arch/index.html?q=rest vs
Я б не змішував конкретну реалізацію на конкретній мові програмування з такими фундаментальними речима, як REST. Спочатку ми будуємо REST, а вже потім в ньому самому ідуть самі асинхронні запити.
Якщо помиляюсь, прошу мене виправити.
REST, как архитектурный шаблон не особо не заточен под асинхронную архитектуру. Та же ситуация нблюдается в REST, как технлогия. И да, вы ошибаетесь, в самом REST’е не могут идти сами асинхронные запросы
У вас какой-то пунктик к Java/JVM?
Та ні, це у вас якийсь пунктик відносно кешування GET-запитів;-)
И да, вы ошибаетесь, в самом REST’е не могут идти сами асинхронные запросы
Так вони і не повинні. Де сказано, що повинні?
Людина описала основи REST, а потім приходить бравий гусар і каже: “Ваш rest — фігня, бо там фігово все з асинхронними запитами”.
А ти такий стоїш і не знаєш, що відповісти.
Так вони і не повинні. Де сказано, що повинні?Людина описала основи REST, а потім приходить бравий гусар і каже: «Ваш rest — фігня, бо там фігово все з асинхронними запитами».
А ти такий стоїш і не знаєш, що відповісти.
Бывает и другая ситация. В начале проекта прискакивает всадник на белом коне (аля архитектор). И молвит он слово — рест фореве. И в начале реализации он «ускакивает». Потом ты приходиш на проект и понимаеш, что все очень грустно.

Тут я теж погоджуюся, але це тема для окремої статті.

1. как осбтаят дела с асинхронными вызовами?
HTTP — синхронный протокол.
Как обстоят дела с асинхронными вызовами в синхронных протоколах? — Печально.
REST как раз таки позволяет решить эту проблему в довольно удобный способ restcookbook.com/...asynchroneous-operations (первая ссылка из гугла)
2. куда будет ложится REST, если архитектура далека от CRUD и GET/POST/DELETE/PUT/PATCH недостаточно?
Ровно та же проблема что и в предыдущем вопросе про «вызовы». Для начала надо осознать понятие ресурса. Та и практика веб-разработки говорит что и одного POST достаточно :)
3. что делать, если для чтения необходимо передать сложный объект/массив обектов?
И в чем проблема?
4. что делать, если надо «ложиться» не на HTTP?
REST — это архитектурный подход, при большом желании вы можете использовать его поверх другого протокола. Но все же этот подход рассчитан на наиболее полное использование HTTP (куда больше чем просто транспортный уровень)
5. что делать, если необходимо выполнять пакетную обработку?
В чем именно проблема? Если в тайм-аутах, то см ответ на пункт 1. Если в объеме данных, то подобные проблемы будут с любой распределенной системой.
По мне, так, рост имеет смысл использовать, если вы хотите предоставить публичный API
REST задает общие правила, предоставляет общие паттерны, такой себе «convention over configuration». REST стимулирует вас разобраться вашей предметной области, тут можно попробовать привести аналогию REST vs RPC <-> OOP vs Procedural programming.
И еще вопрос:
чем дизайн публичного АПИ отличится от дизайна не публичного АПИ?
HTTP — синхронный протокол. Как обстоят дела с асинхронными вызовами в синхронных протоколах? — Печально.
REST как раз таки позволяет решить эту проблему в довольно удобный способ restcookbook.com/...asynchroneous-operations (первая ссылка из гугла)
И много вы знаете реализаций высоконагруженных систем с этим походом, особенно имея в распоряжении websocket & mq?
Ровно та же проблема что и в предыдущем вопросе про «вызовы». Для начала надо осознать понятие ресурса. Та и практика веб-разработки говорит что и одного POST достаточно :)
Так это уже совсем не «тот» REST, который ресуют евангилисты REST’а. Не говоря уже о проблемах, с которыми столкнется клиент привыкший к «тому» REST’у (см. habrahabr.ru/...mpany/yandex/blog/265569 , п.п. 7,15): GET как POST, как бы нарушения рекомендаций RFC и т.п.
И в чем проблема?
Да сообо не в чем, разве что в большенстве серверах дилна URL ограничена, URL становится оочень страшный, ну и проблему POST as GET см. в предыдущем ответе.
REST — это архитектурный подход, при большом желании вы можете использовать его поверх другого протокола. Но все же этот подход рассчитан на наиболее полное использование HTTP (куда больше чем просто транспортный уровень)
См. вопросы 1 и 5
В чем именно проблема? Если в тайм-аутах, то см ответ на пункт 1. Если в объеме данных, то подобные проблемы будут с любой распределенной системой.
Проблема в том, что вы не сможете за один запрос обратится к нескольким ресурсам на чтение, запись, обновление, кто знает еще чего. Это ограничено архитектурой REST.
REST задает общие правила, предоставляет общие паттерны, такой себе «convention over configuration». REST стимулирует вас разобраться вашей предметной области, тут можно попробовать привести аналогию REST vs RPC <-> OOP vs Procedural programming
Я бы не проводил аналогию мягкого со вкусным аля REST vs RPC <-> OOP vs Procedural. Ну и да, статей REST vs RPC, REST vs ??? не хватает, т.к. обычно описание явно или неявно скатывается к тому, что REST лучший подход покрывающий все и вся. «Последние» веяния моды???
чем дизайн публичного АПИ отличится от дизайна не публичного АПИ?
REST сейчас очень распространен, его не знает разве только начинающий джуниор, есть куча реализаций на клиентской и серверной сторонах, на любом языке (как то все это мне напоминает ситуацию с SOAP в 2000-ых — такие же дифирамбы ему пели). И да, его очень просто использовать под Вебом. «Отличие публичного АПИ отличится от дизайна не публичного АПИ» заключается в том, что вы неограничены распространненостью (модностью???) какого-либо архитектурного подхода и вправе вбрать оптимальное решение — с моей точки зрения не REST.

Вы читали статью или ссылки к ней? Или комментарии? Вы уже не первый комментатор, который говорит про 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.

Вы читали статью или ссылки к ней? Или комментарии? Вы уже не первый комментатор, который говорит про HTTP и подменяет это понятие на REST. Если читали, то это, наверное, я не смог передать суть подхода.
Я не знаю не одной реализации REST не на HTTP. Кинте пруф. Так же я не понял, что вы влаживаете в понятие WWW аля REST?
Посмотрите публичные API гигантов. Twitter нагруженная система?
Так я же об этом и говорю — хорош для публичного API и не более того.
Яндекс пишет об HTTP, а не REST. У REST нет RFC, его первое упоминание и более менее строгое описание здесь — www.ics.uci.edu/...ation/rest_arch_style.htm.
Распространен не REST, а подделки в RPC-стиле на основе HTTP.
Жду пруф на не HTTP реализацию.
Жду пруф на не HTTP реализацию.

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

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

Посмотрите на CoAP — datatracker.ietf.org/doc/rfc7252, это протокол для embedded на основе REST.

С чего вы взяли, что REST — это лучший подход? Я писал в статье просто об основах, попытался описать как его понимаю.

Жду пруф на не HTTP реализацию
Как насчёт локальной системы контроля версий? Есть ресурс, есть к нему обращение для получения состояния, есть переходы между состояниями. Нет HTTP. Подходит?

И к чему это? Тренд чего? Не зрелости технологии?
Вот тут www.google.com/...p;cmpt=q&tz=Etc/GMT-3 другая ситуация (жаль, нет данных с 2000-го) и что?

Эта ссылка была к:

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

Да, с этим соглашусь. Когда SOAP только появился — тренд по нему рос. Когда технология достигла зрелости — она заняла свою нишу — Ынтерпрайз, а REST почти вытеснил его с публичного Веба. Только не понятно, какую нишу займет REST, кода он дозреет. Осмелюсь предположить — публичный Веб API.

И много вы знаете реализаций высоконагруженных систем с этим походом, особенно имея в распоряжении websocket & mq?
1) Высоконагруженный — это слово махинация. Ну скажу я что знаю точно 2 таких, сам делал :).
2.1)Веб-сокеты далеко не всегда можно использовать по причинам безопасности.
2.2)Очереди не получится использовать с не северными клиентами: браузерами, мобилочками.
3) Вы спросили «как обстоят дела», а не «является ли РЕСТ оптимальным решением для». Это разные вопросы.
Так это уже совсем не «тот» REST, который ресуют евангелисты REST’а.
Я не знаю что там рисуют какие-то евангелисты, я озвучиваю свое мнение.
3. что делать, если для чтения необходимо передать сложный объект/массив обектов?
Да сообо не в чем, разве что в большинстве серверах длина URL ограничена, URL становится оочень страшный, ну и проблему POST as GET см. в предыдущем ответе.
Понял: вы в ГЕТе хотите передавать большой объект?
От только не понятно зачем? Приведите ваш пример.
Есть типичный сценарий с поиском: там можно применить ПОСТ, тут очень важно понимать что «ресурс» !== «объект». В сценарии с поисковым запросом, ресурсом является «поиск», а не «условия поиска».
Проблема в том, что вы не сможете за один запрос обратится к нескольким ресурсам на чтение, запись, обновление, кто знает еще чего. Это ограничено архитектурой REST.
1) А зачем оно вам надо? И как это решают другие подходы?
2) С большой долей вероятности, возможно выделить «ресурс» (или HATEOAS-цепочку) который будет содержать в себе обработку батча. Это по моему опыту, но вашу задачу я не знаю.
REST сейчас очень распространен, его не знает разве только начинающий джуниор
Мой опыт говорит о другом: Веб-АПИ делает кто попало и называет это РЕСТом, что как правило является не правдой. Я так понял у автора статьи похожая статистика, поэтому статья и появилась.
«Отличие публичного АПИ отличится от дизайна не публичного АПИ» заключается в том, что вы неограничены распространненостью (модностью???) какого-либо архитектурного подхода
Очень странное определение.
вправе вбрать оптимальное решение — с моей точки зрения не REST.
Еще более странное утверждение. Оптимальность решения зависит от задачи (и часто даже от команды которая делает и потенциальных пользователей). Для некоторых задач оптимален РЕСТ, для других оптимален другой подход.
Не уверен в том что вы хотели сказать, но в такой формулеровке я увидел в вашем комментарии в основном «мне не нравится РЕСТ поэтому он плохой». Возможно это стилистика речи и я просто ошибся.
Веб-сокеты далеко не всегда можно использовать по причинам безопасности.
А розкажіть трошки детальніше, бо я щось не второпав, про яку саме безпеку йде розмова? Опишіть ситуації, які, на вашу думку, суттєво відрізняються від звичайного HTTP
Опишіть ситуації, які, на вашу думку, суттєво відрізняються вид звичайного HTTP
Я бы вам рассказал, но я сам на такой вопрос не получил внятного ответ :)
А розкажіть трошки детальніше, бо я щось не второпав, про яку саме безпеку йде розмова?
Точно не помню, но кажись был не возможен апгрейд протокола, поскольку админы не хотят открывать ничего более того что уже открыли (рекомендовано поставщиком сетевого оборудования). Возможно сейчас эта проблема не актуальна, но несколько лет назад и сам сталкивался, и часто слышал что опсы настраивают безопасность в сети так что вебсокеты не работают. Так же сталкивался с ситуацией (и слышал о подобных ситуациях), когда или антивирус на стороне клиента или софт безопасности внутри сети сервизов резал пакеты при работе вебсокетов.
Так это уже совсем не «тот» REST, который ресуют евангилисты REST’а. Не говоря уже о проблемах, с которыми столкнется клиент привыкший к «тому» REST’у (см. habrahabr.ru/...mpany/yandex/blog/265569 , п.п. 7,15): GET как POST, как бы нарушения рекомендаций RFC и т.п.
Ну очень зависит от реализации. А что ты делаешь когда методу для работы не хватает трех аргументов? Дядя Боб говорит что в этом случае у вас либо метод делает излишне много (больше одной вещи) либо где-то упущена абстракция и нужно передавать её, а не её свойства.
И в чем проблема?
Да сообо не в чем, разве что в большенстве серверах дилна URL ограничена, URL становится оочень страшный, ну и проблему POST as GET см. в предыдущем ответе.
Например в данном случае, по-моему, очень характерной проблемой будет проблема фильтра — когда в GET пытаются всунуть дикую уйму параметров фильтрации. Логично предположить что не хватает абстракции фильтра. Тогда мы создаём (POST) фильтр — переводим систему в то состояние в котором такой фильтр существует. Затем запрашиваем выдачу в соответствии с фильтром таким-то. Просто как пример. Решений даже в рамках текущих ограничений дикое множество.
Проблема в том, что вы не сможете за один запрос обратится к нескольким ресурсам на чтение, запись, обновление, кто знает еще чего. Это ограничено архитектурой REST.
Нет, не в этом проблема. Проблема в том что вы не правильно это используете. Вам, скорее всего, снова не хватает абстракции. Создайте ресурс аггрегирующий вышеописанные. Назначте ему такой переход между состояниями (команду) которая как раз в реализации обратится к нескольким ресурсам на чтение, запись, обновление, кто знает еще чего.
REST сейчас очень распространен, его не знает разве только начинающий джуниор
Снова не совсем верно. Скорее REST сейчас очень распространен, все думают что его отлично знают и умеют готовить. И когда что-то не получается катят бочку на него.

Мой ответ был близким к ответу 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. Да там много интересных идей, но некоторые из них, мне не нравится. Гляньте ссылки к статье.

Я понимаю, что автор читал диссертацию (не знаю как в Штатах, а у нас там люди и покруче из**ться), но всё-же, зачем из простого делать сложное?

REST — REpresentational State Transfer. Я перевожу это так — передача/изменения состояния через представления.

ОБРАЗЕЦ передачи состояний — и всё кагбэ попроще?
REST — это архитектурный стиль, некоторое множество ограничений
там их не так много, ШЕСТЬ, простое перечисление имхо куда лучше, чем «некоторое множество»
Не существует какого-то единого стандарта, который бы полностью описывал REST
RESTful конечно размытое, но СУЩЕСТВУЮЩЕЕ понятие

LOL

Кагбэ автор написал «я перевожу это как». Как переводите и интерпретируете это вы, это уже ваши проблемы.

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

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

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

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

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

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

REST удивительная вещь. Кто бы и что бы о нём не писал — всегда получается бла-бла-бла. Как правило, это говорит о религии. Есть то, во что надо верить, не задавая лишних вопросов.

ЕДИНСТВЕННАЯ польза REST — это кеширование. Других преимуществ у данной технологии нет. Но и этого достаточно. Вы просто знаете что в любой момент времени тот ресурс что находится у вас на руках — является целостным. И что запросив его ещё раз, вы не получите ничего другого кроме факта что он есть. Всё что он может сделать — это перестать существовать.

Естественно, есть изменяемые ресурсы. Но опять таки, это всё равно ресурс, и получая изменившийся ресурс вы ждёте от него такой же типизации. Может это и глупо с точки зрения логики программирования, но зато отлично вписывается в логику ЧЕЛОВЕЧЕСКУЮ: а именно — шаблонное мышление. Всё что вы получили посредством REST — вы вправе считать шаблоном.

Придумывать что-то ещё сверх этого — значит становиться граммарнаци от программирования, и быть посланным всеми вменяемыми кодерами. Неужели так сложно понять, что МЕНЬШЕ — ЗНАЧИТ ЛУЧШЕ. И чем проще технологию освоить, тем более она востребована.

PS. Делать проект исключительно на REST — всё равно что общаться только существительными, без глаголов. Вас даже могут понять. Но над вами будут смеяться.

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

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

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

Дим, ну это ж Джава! Там по-простому нельзя. Только SOAP и прочая жесть.

Посмейтесь над WWW, который основан на REST.

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

над большинством Amazon API.

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

Остальных названных не видел, но подозреваю, и там проблемы.

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

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

Вообще, мне кажется, что вы доказываете примерно одно и то же, но на разных языках...

Если бы было так, то 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.

Давайте, на конкретных примерах. Возьмем, для начала

Нет, возьмём, для начала: docs.aws.amazon.com/...tructure-of-a-get-request — это то, с чем я общался. Где тут указание на ресурс, которым должна быть локальная часть URL? Нету, ресурс пустой на все случаи.

Ваши примеры с S3 неинтересны, потому что S3 это уже хранилище данных, и там всё банально. А вот EC2 это уже управление сущностями, которые не есть плоские данные, и там всё их игнорирование принципов вылазит в полный рост. И, чтобы это исправить, они тут же вводят хак:

docs.aws.amazon.com/...Instance_Idempotency.html

в то время как настоящий REST тут бы сделал создание инстанса через что-то вроде POST /instance/${id_by_client}?new=1, или POST /instance/?new=1 с возвратом от сервера URL созданного инстанса.

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

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

С вашим примером 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 это чтение ресурса. Ресурс не меняется, меняется только его представление. Веб-страница представлена каждый раз по-разному.

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

Так говорят обо всех новомодных течениях. Но мода проходит. А остаётся только самое важное, самое востребованное.
Идеологии же принято раздувать — ведь как иначе выдоить из корпоративных монстров сотенку-другую лямов под то что гроша выеденного не стоит.

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

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

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

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

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

Причина этому есть одна, и очень простая, она же древнее разногласие математиков с программистами:
У программистов переменная for(i=0;i<n;i++)
У математиков ∑ i1, i2... in

Иными словами, у математиков переменная не является переменной. Она либо чему-то равна, либо имеет область значений. Но в её функцию не входит ХРАНЕНИЕ состояния, которое может измениться. Она по сути и означает состояние.

У программистов переменная — это именно память. То есть факт, что переменная поменяла значение, или в общем случае ссылку — ничего нового не привносит, это ожидаемое поведение. По этой же причине переменные стараются типизировать, чтобы ЧЕЛОВЕЧЕСКАЯ логика не нарушалась, чтобы кроме значения переменная несла информацию ещё и о шаблоне памяти.

По сути REST — это тот же математический принцип: плодить имена чтобы за каждым из них был детерменированный объект. С точки зрения программирования это неудобно, поскольку основная работа программиста — именно изменения. С точки зрения работы кода, и для прикладных задач верхнего уровня — это приятно, поскольку гораздо легче ВЛАДЕТЬ копией, нежели ссылаться на зависимость. С точки зрения ИЗУЧЕНИЯ, в частности чужого кода — REST является адовой технологией, поскольку ВЫЖИРАЕТ память человека под свои избыточности, тогда как память человека весьма ограничена.

PS. Попробуйте-ка в низкоуровневом программировании заняться REST, а мы поулыбаемся. Там ограчиненный ресурс всё ставит на свои места: Только данные, только действия над ними, только зависимости реализуемые через данные. Иными словами, тот же REST, но в цифровой форме, и уже оснащённый полным набором инструментов.

Вот таким выгодно держать и прикладное программирование: ШАБЛОНЫ должны иметь REST-архитектуру, а переменные данные — свои законы жизненного цикла, подчиняющиеся своим протоколам, неважно какими каналами данных они идут или в каких структурах хранятся.

ЕСЛИ этого избегать — получается ситуация, что просто создаётся лишний слой ненужного кода по выведению REST на передний край, а логики — в глубокие дебри фреймворков и ядерного кода. Да, красиво. Но дорого. Особенно дорого, когда это потом требуется менять.

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

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

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

Я говорю о типичных. Математика точно также имеет богатый набор, а уж языки и стандарты моделирования тем более.
Но для того чтобы овладеть математическим инструментарием, нужно иметь математический склад ума. Достигаемый ТРЕНИРОВКОЙ короткой памяти и прокачиванием специальными шаблонами.
Для того чтобы овладеть лучшими практиками программирования — наоборот, требуется типичный склад ума, основанный на шаблонном распознавании, близком связывании, и объектно-ориентированное программирование как нельзя лучше к этому подходит.

Когда выгодны декларативные языки: для описания процессов. Когда процесс и является объектом. Главная особенность этого небольшого множества задач — есть огромные «подводные» течения, которые условно можно объединить во фреймворк или архитектуру. К примеру, чтобы петух прокукарекал утром, ему не нужно знать астрономию.

Со временем таких задач становится всё больше. Из-за удешевления технологий, усовершенствования «ядерного» кода, и соответственно падения цены изменений (в том числе рисковой составляющей).

Пример: раньше интернет-магазин писался полностью на функциональных решениях. Сейчас — как правило чисто декларативная задача. И соответственно, REST для неё как нельзя более кстати подходит.

А онлайн-казино так и не стало одинаковым для всех. И следовательно, по сей день все они существуют на костылях и велосипедах, пусть и хорошо смазанных. Больше всего я удивляюсь той же ситуации в банковской отрасли.

работала и будет работать на ajax через json
Как это исключает REST, противоречит ему и что значит «работать на ajax через json»? Вроде все предложения так лаконично сложены из умных слов, а техническая составляющая на уровне пятилетнего (может я, конечно, отстал от IT-сленга, но тогда вместо кидания камнями и заострения на этом внимания, объясните как всё же это исключает REST?). Вы завязываете игровую логику (что бы Вы под этим не подразумевали) на AJAX и JSON? Как вообще логика может работать на AJAX? Ладно, распрашивать каждое слово этого абзаца можно вечно...
Без особых усилий к приведению процесса к какому-либо удобоваримому формату
Что такое приведение процесса к формату?
разногласие математиков с программистами
Давайте жить в мире. Причина использования «ajax через json» — это разногласие пр... да блин, при чём здесь математики?
У программистов переменная for(i=0;i<n;i++)
У программистов переменная — это не цикл и не только в цикле переменные используются
У математиков ∑ i1, i2... in
Сумма чисел не так пишется у математиков, может программист бы так написал, но тогда зачем сравнивать цикл и сумму?
Она либо чему-то равна, либо имеет область значений
А чем Вам x, который принимает одно из значений в области значений, не переменная? Я здесь накатал еще какой-то комментарий про «что такое по Вашему переменная», но понял, что мне это не важно.
Но в её функцию не входит ХРАНЕНИЕ состояния, которое может измениться.
Я прошу прощения, но мне кажется, что математики и программисты решают разные задачи, области их (представим людей, как инструменты) применения разные. Могут пересекаться и дополнять друг друга (и могу вас уверить, что это прекрасный дуэт), но бороться и выяснять кто круче (в чём?)? Зачем? И науки дополняющие, но не взаимозаменяемы. Как сравнивать людей, которые делают рельсы и людей, которые делают поезда (и уверяю Вас, поезда в данном случае делают математики).
Она по сути и означает состояние.
Так переменная в математике либо чему-то равна (состояние не меняется), либо имеет область значений, а значит в какой-то момент времени принимает одно из этих значений (если мы всё же говорим о состоянии).
То есть факт, что переменная поменяла значение, или в общем случае ссылку — ничего нового не привносит, это ожидаемое поведение
Напомнило те забавные случаи, когда переменная стала ссылаться на ноль, а в коде она находилась в знаменателе. Хохоту было...
По этой же причине переменные стараются типизировать, чтобы ЧЕЛОВЕЧЕСКАЯ логика не нарушалась, чтобы кроме значения переменная несла информацию ещё и о шаблоне памяти.
Любитель не усложнять... я правда стараюсь не обсуждать каждую строчку, но моя ЧЕЛОВЕЧЕСКАЯ логика подсказывает мне, что есть люди, которые разберутся в этом предложении и скажут мне, что я м*дло и там всё просто и понятно, с объясненияим и ссылками на котиков, которые жонглируют шаблонами памяти, чтобы я становился умнее.
математический принцип: плодить имена чтобы за каждым из них был детерменированный объект
Не могу автора принципа найти :(
основная работа программиста — именно изменения
Из контекста, я так понимаю, что изменения переменных? Так получается, что всё отлично, чем больше «имён», тем больше изменений мы можем внести. Если выделять для каждого «напложенного имени» (я так понимаю, Вы имеете в виду представление) отдельный функционал, который является таки понятием в вашей системе, то изменение правил именно в этом понятии, повлечёт изменение кода только в этом «напложенном имени» и не придётся костылять, чтобы не задеть остальной функционал «ajax через json».
Попробуйте-ка в низкоуровневом программировании заняться REST, а мы поулыбаемся.
Где и с кем заняться REST?
Там ограчиненный ресурс
Ограниченный? Чем?
Только данные, только действия над ними, только зависимости реализуемые через данные.
Так это и есть REST?
но в цифровой форме
Настолько низкоуровневый?
оснащённый полным набором инструментов
Так чем ограниченный?
ШАБЛОНЫ должны иметь REST-архитектуру
ШАБЛОНЫ — это действия? это правила поведения? это команды? это контроллеры? это twig? это мышление?
свои законы жизненного цикла
законы улиц. Я пытаюсь понять о чём Вы пишете и если слова переменная заменить на ресурс, а ШАБЛОНЫ — на действия над ресурсами, то доля смысла в этом есть и тогда понятно, каким образом Вам помочь:
Не стоит разделять ШАБЛОНЫ и переменные, значения переменных представляют состояние системы, а ШАБЛОНЫ позволяют переводить систему из одного состояния в другой. Но переменные бывают связаны, у некоторых переменных бывает очень много связей, но если разбирать определённый ШАБЛОН, то в рамках него могут быть необходимы только некоторые связи. И чтобы не загромождать ШАБЛОН ненужными связями, мы делаем представление нашей переменной, которое показывает её значение именно в контексте определённого ШАБЛОНА. Это позволяет в нужный момент времени заниматься только нужными связями, заниматься только определённым ШАБЛОНОМ, работать с данными, представленными (хотелось бы) объектами из предметной области именно этого ШАБЛОНА и абстрагироваться от того, как эти модели связаны с остальными ШАБЛОНАМИ и переменными.
подчиняющиеся своим протоколам, неважно какими каналами данных они идут или в каких структурах хранятся
Здесь аналогию я не смог додумать...
ЕСЛИ этого избегать — получается ситуация, что просто создаётся лишний слой ненужного кода по выведению REST на передний край, а логики — в глубокие дебри фреймворков и ядерного кода. Да, красиво. Но дорого. Особенно дорого, когда это потом требуется менять.
Красиво? Я бы прокомментрировал этот абзац, но он мне кажется далёким от истины. Дебри фреймворка из-за REST? Да он позволит тебе не закладывать в твои модели все возможные над ним действия и всё возможное поведение в разных ситуациях. Ведь так происходит и в жизни. Ты приносишь ноутбук в кафе, чтобы покодить и посмотреть ленту фейсбука, тебе важен заряд батареи, количество тематических наклеек, наличие наушников и достаточное количество USB входов для подзарядки всех твои павербэнков, но вот ты приносишь тот же ноутбук на продажу и тебе совершенно неважно ли есть остаток батареи в нём, тебе не важно количество USB, тебе важно, чтобы они не выглядели вывернутыми, потому что мама вечно дёргает провод, на котором висит телефон и вход USB уже на пол шишечки снаружи, тебе не нужны наклейки, даже наоборот, тебе нужно от них избавиться, а какой они тематики уже не важно, тебе нужна коробка и документы, ты смотришь на ноутбук по другому, теперь это товар, а не окно в твой виртуальный мир, дружок, но физически — это тот же ноутбук. При чём обрати внимание, что сущностей 4, а ресурсов 2:
1. Ноутбук и наушники в контексте использования
2. Ноутбук, коробка и документы в контексте продажи
Вот тебе и представления для определённых действий, можно еще поподробнее описать, что входит в каждое представление в понятие ноутбук, они разные.
Всё таки прокомментировал... Простите за такой грубый и детский пример, но это можно объяснить тем, что я не старался.

Религия? После этого слова захотелось прочитать комментарий. Ваш комментарий походит на религиозную проповедь, особенно степенью информативности.

Зачем заблуждать народ? Вы говорите про CRUD или какое-то своё представление о REST, каждый д*очит REST как он хочет, каждый называет RESTом то, что он видел и то, что его коллеги называли RESTом, то, что умные ребята называют RESTом. Целью данной статьи является как раз избавление людей от этого множества определений.

ЕДИНСТВЕННАЯ польза REST — это кеширование. Других преимуществ у данной технологии нет. Но и этого достаточно. Вы просто знаете что в любой момент времени тот ресурс что находится у вас на руках — является целостным. И что запросив его ещё раз, вы не получите ничего другого кроме факта что он есть. Всё что он может сделать — это перестать существовать.
Какая из букв в аббревиатуре REST натолкнула Вас на мысль о кэшировании? Видимо, Дмитрий совсем забыл об этом написать. Мне кажется, что он хотел описать архитектурный подход REST, а не какие-то методы и нюансы его имплементации. Если ваше приложение написано в стиле REST, то добавить кэширование будет намного проще, потому что будут выделены все ресурсы и действия с ними, которые можно закэшировать.
Польза REST? У меня в голове представляется настолько красивый и грамотно написанный проект с использование REST, что до фул REST его не дотягивало только отсутствие кэширования.
Ресурс ничего не умеет делать кроме как «переставать существовать»? Какие грустные ресурсы. Мы говорим об интернет-магазине? Мне надо понимать на каких проектах Вы использовали эту REST, как Вы говорите, технологию.
Естественно, есть изменяемые ресурсы. Но опять таки, это всё равно ресурс, и получая изменившийся ресурс вы ждёте от него такой же типизации. Может это и глупо с точки зрения логики программирования, но зато отлично вписывается в логику ЧЕЛОВЕЧЕСКУЮ: а именно — шаблонное мышление. Всё что вы получили посредством REST — вы вправе считать шаблоном.
К чему здесь слово шаблон? В «логике программирования» изменённый ресурс должен поменять тип? Используя «человеческое» шаблонное мышление, я буду использовать то, что используют все, если я не знаю другого лучшего способа, это, пожалуй, многое объясняет в Вашем сообщении.
Придумывать что-то ещё сверх этого — значит становиться граммарнаци от программирования, и быть посланным всеми вменяемыми кодерами. Неужели так сложно понять, что МЕНЬШЕ — ЗНАЧИТ ЛУЧШЕ. И чем проще технологию освоить, тем более она востребована.
Ну поверх шаблоннов и кэширования даже добавить нечего.
Кодеры редко вырастают в программистов и я не считаю, что стоить слушать их мнения.
Меньше — значит лучше? Меньше чего? Аргументов? Сложно понять? Проще технологию? Мне кажется, или всё же Вы имели в виду «Проще — значит лучше»?
PS. Делать проект исключительно на REST — всё равно что общаться только существительными, без глаголов. Вас даже могут понять. Но над вами будут смеяться.
Я Вас Отрицание Понимание Причина Отсутствие Аргументов. Я даже не понял метафоры. Может лучше так:

Делать проект исключительно на REST — всё равно, что общаться без матов. Вас поймут и вы никого не оттолкнёте, но прямо сильно изъе*нуться не получится.

На счёт статьи, как по мне, так она довольно обрезанная, это стало понятно из комментариев людей, которые так в итоге ничего и не поняли. Стоит разобрать более подробно! С большой степенью уверенности могу сказать, что почти никто не прочитал диссертацию Роя (я в том числе).

P.S. В своём проекте стоит быть граммар наци (по крайней мере после того, как он начал приносить деньги).

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

http ://somebank.org/account/12345/close
может относится к REST поверх HTTP? Ведь эта ссылка указывает не на ресурс, а на действие с ним (close). В моём понимании такие ссылки должны указывать на связанные ресурсы (например /account/12345/transactions/ - список транзакций для данного счёта). В то время как перечень операций с ресурсом ограничен простыми HTTP методами (GET, POST, PUT, PATCH, DELETE), и этот список можно узнать сделав запрос OPTION для ресурса.
Я всё удивляюсь примеру про счёт в банке, который копируют с википедии.

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

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

Я конечно не читал диссертацию Роя, и возможно в ней нет ничего про то что 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-методы нам не нужны, они просто добавляют дополнительные фишки — идемпотентность и т. п. Представьте себе какой-нибудь текстовый протокол или бинарный, не суть важно, и представьте, что вам нужно как-то менять состояние ресурса, читать его и видеть список возможных действий + пара ограничений (коммуникация без состояния и без сессии клиента).

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

С таким форматом ссылок «на действия» это получается тот же самый RPC. Просто подмена одного стандарта на другой. Т.е. вместо того что бы клиент знал, что он может вызывать у ресурса GET, POST, PUT, DELETE, он будет знать, что ему нужно просто всегда вызывать POST на ту ссылку которую он найдёт в ответе на предыдущий запрос. Т.е. теряется какой либо смысл всех этих HTTP методов, если можно обойтись только GET и POST, а действие указывать в URL (например: /posts/123/comments/add_comment, /posts/123/comments/456/delete_comment)

Все же рекомендую прочитать часть диссертации и хотя бы 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. Приведите примеры, как бы вы реализовали копирование слайда, сортировку слайдов, как бы их заблокировали для редактирования.

В указанной вами ссылке как раз всё верно оформлено в плане того что uri указывает на ресурс:

<link rel="/linkrels/appointment/addTest" uri="/slots/1234/appointment/tests«/>
Как видите здесь uri указывает на ресурс-контейнер тестов, в который можно добавить новый тест. А добавить его туда можно стандартным (в случае HTTP) способом — через метод POST.

По моему в примере из википедии что то напутали, вот как раз rel может содержать что угодно, и какие угодно «глаголы» и «действия» — это просто идентификатор, который позволяет клиенту абстрагироваться от прямых ссылок.

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

<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>

Ни одна из ссылок (которые в uri) не содержит ни одного действия — это всё ссылки на ресурсы. Что делать с этими ссылками на ресурсы (читать их через GET, или что то добавлять через POST) знает клиент, но он не знает сами ссылки. Он знает только rel по которому он может найти интересующий его ресурс для нужного ему действия.

Что-то у нас с вами не так, я вроде как об этом же и говорю)

Наверное да. Но я ведь начал разговор с того, что в примере с википедии uri (href) содержит не адрес ресурса, а смесь ресурса и какого то уникального действия над ним.

Там в примере не ресурс, а его представление — 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>

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

Так ведь я не против ссылок. Я за них обеими руками. Меня просто до глубины души поразило что в википедии в URL-е используется глагол, как в каком то RPC :)

Это одна из причин по которой писал статью, что REST представляют как «CRUD-протокол» и работают с ним в виде RPC.

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

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

Все действия, которые не вписываются в HTTP методы (CRUD) для конкретного ресурса можно реализовать теми же самыми методами для другого ресурса. Например может быть ресурс /copier, в который с помощью метода POST добавляется «задача» на копирование одного или нескольких ресурсов. Эта «задача» — такой же ресурс, и на сервере она может выполнятся асинхронно, а клиент, делая GET запрос к этой «задаче», будет получать её текущее состояние (например «выполнено: 56%»).
Такой подход позволяет вписать в терминологию CRUD практически любую предметную область.

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

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

Про это уже писали на Хабре (в блоге Яндекса) в первом пункте.

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

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

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

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

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

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

Смоделируйте сортировку ресурсов, копирование, активацию/деактивацию ресурса и т. д.
сортировка ресурсов — это вопрос отображения. если вы хотите получить данные отсортированные, можно испольовать что-то типа:
GET /api/resources?sortBy=name

копирование — хз что это такое, типа создание нового ресурса с параметрами существующего?
POST /api/resources
(body объекта, который копируете)

Активация/деактивация:
POST /api/resources/deactivated
{id: 1234}

Т.е. подход к дизайну интерфейса — формулировать не глаголами, а существительными. Вместо Деактивировть — получить деактивированный ресурс = добавить ресурс в коллекцию деактивированных ресурсов и т.п.

Капець, як все складно...

Понятие “состояние” в статье, на мой взгляд, применяется не к тому объекту. Статья описывает REST как способ управлять состоянием системы.
На самом деле речь идет о состоянии коммуникации и клиента — вся информация про клиента, его состояние и состояние соединения передается в каждом запросе:
“We next add a constraint to the client-server interaction: communication must be stateless in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.”
И еще несколько цитат:
“...All REST interactions are stateless....1) it removes any need for the connectors to retain application state between requests, thus reducing consumption of physical resources and improving scalability; 2) it allows...
...The stateless nature of REST allows each interaction to be independent of the others, removing the need ...
...The goal is to improve server scalability by eliminating any need for the server to maintain an awareness of the client state beyond the current request...”

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

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

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. Считаю, что это тянет на отдельную статью и желательно с практическими примерами.

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

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

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

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

На графе состояний две надписи над переходами неправильные.

Да, не заметил, когда рисовал. Это правда больше «концептуальная» картина, чтобы натолкнуть мысли в нужное русло, но такие неточности раздражают. Спасибо!

Чи є переваги REST над SOAP ?

В мене була ситуація коли через АПІ треба було завантажувати великі файли. Через SOAP я не знайшов як це зробити. Я через REST просто — PUT запит і все.

У такому вигляді як ви описали я РЕСТ не зустрічав. Щоб список методів доя представлення будувався сервером і повертався клієнту

В мене була ситуація коли через АПІ треба було завантажувати великі файли. Через SOAP я не знайшов як це зробити. Я через REST просто — PUT запит і все.
НЕ думаю що передавати великі файли через SOAP чи REST це гарна думка
У такому вигляді як ви описали я РЕСТ не зустрічав.
це тому що його використовують тільки як RPC

Я очень поверхностно знаком с SOAP и лишь немного с ним работал на практике. Поэтому не возьмусь судить о преимуществах.

У такому вигляді як ви описали я РЕСТ не зустрічав.

Именно поэтому я решил попробовать со статьей, ибо то, что я вижу — это, в подавляющем большинстве, RPC.

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

  • Клиент не содержит бизнес-логики. Если действие доступно, например, снять деньги со счета, то он рисует соответствующую кнопку и не хранит у себя выражения вроде “if (account.balance.amount > 0)”. А что если завтра эти правила поменяются?
  • Независимость от URL. Клиент по-просту о них не знает, у него есть только entry point и не более. Это позволяет менять нам URL как угодно и на что угодно. Например, разобьем приложение на микросервисы, а клиент даже не узнает о том, что шлет запросы на другой URL. (CORS настроим, если речь о клиенте в браузере).
  • Разбиваем ресурсы на “под-ресурсы”. Например, вместо того, чтобы отдавать один большой ресурс, мы можем изучить запросы пользователи и разбить на “под-ресурсы” все так, что ресурсы сервера будут утилизироваться максимально эффективно.
  • И другие.

Здесь как с тестами, однажды попробовав, уже сложно вернуться назад.

Что касается реальных примеров, то есть положительная тенденция. Github API, Twitter API и другие гиганты уже как минимум отдают ссылки на ресурсы, многие из них уже отдают ссылки на возможные действия.

Тут есть просто одна загвоздка, возможные действия, не всегда так “дешево” вычислить иногда легче сказать, что оно доступно и отдавать ссылку всегда, а уже при выполнения реального запроса отказать клиенту.

К примеру, здесь — www.youtube.com/watch?v=1xqxVai_siQ парень рассказывает, что они делали подобное для DHL и показывает пример на практике.

Спасибо за статью, довольно интересный обзор. Есть несколько вопросов по ходу дела.

Сейчас и работаю над такой версией API, где у нас есть список возможных действий, которые отдаются клиенту.
Похоже на WSDL.
Клиент не содержит бизнес-логики. Если действие доступно, например, снять деньги со счета, то он рисует соответствующую кнопку и не хранит у себя выражения вроде «if (account.balance.amount > 0)».
А если действие скажем по переводу денег доступно, но скажем не больше 10 баксов, а клиент пытается перевести 20? Можно конечно попытаться провернуть операцию и получить отказ от сервера, но тогда зачем создавать список доступных функций. Так же есть вариант бизнес правила, что деньги можно переводить, только если на счету не меньше 100 баксов, наверняка клиент попросит втулить задисейбленную кнопку с надписью, что вам не хватает денег на счету и пополните его плиз, сразу возникает вопрос, как в апи это будет выглядеть и как после пополнения клиент поймет, что теперь ему можно переводить деньги ? (из предположения, что все через апи и страничку мы не перегружаем)
Разбиваем ресурсы на «под-ресурсы». Например, вместо того, чтобы отдавать один большой ресурс, мы можем изучить запросы пользователи и разбить на «под-ресурсы» все так, что ресурсы сервера будут утилизироваться максимально эффективно.
Можно с примером ?
> Сейчас и работаю над такой версией API, где у нас есть список возможных действий, которые отдаются клиенту.
Похоже на WSDL.

Не очень, ИМХО. WSDL статичен.

А если действие скажем по переводу денег доступно, но скажем не больше 10 баксов, а клиент пытается перевести 20? Можно конечно попытаться провернуть операцию и получить отказ от сервера, но тогда зачем создавать список доступных функций.
чтобы не дублировать логику вычисления этой суммы мы на клиенте.
как после пополнения клиент поймет, что теперь ему можно переводить деньги ? (из предположения, что все через апи и страничку мы не перегружаем)
то что страничку не перегружаем не значит что ajax запрещен.

Спасибо за интересные вопросы. Именно, таких я и ждал.

Похоже на WSDL.

Как я понимаю WSDL — это статический перечень возможных действий. В HATEOAS же, мы получаем его динамически, при каждом запросе.

Это еще можно представить себе так:

  1. Вы зная термин, сразу вводите адрес нужной страницы в Википедии (RPC);
  2. Вы бороздите просторы Википедии только по доступным вам ссылкам, которые определяются динамически (HATEOAS).

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

Можно с примером ?

Приведу пример близкий к моей текущей работе.

Допустим, что наше приложение редактирует презентацию — Google Slides. И допустим, что там мы открываем презентацию в которой 200 слайдов. У презентации есть свойства, есть также коллекция слайдов и у слайдов есть содержимое и свойства. И вот перед нами стоит задача спроектировать API для открытия такой презентации и прорисовки дерева со слайдами и для, допустим, редактирования содержимого слайда. Есть множество вариантов, как здесь смоделировать ресурсы. Рассмотрим пару вариантов:

  1. Отдаем все одним запросом;
  2. Отдаем презентацию и в ней коллекцию с представлением слайда, достаточным для отрисовки дерева. При клике на слайд, подгружаем представление слайда и список возможных действий над ним.

Все зависит от того, как ваше приложение, кто, с какой частотой и т. д.

По 1-ому варианту. Если вы загрузите все представление ресурса одним запросом, то это означает, что у вас на клиенте появиться «состояние» ресурса, за которым вам нужно будет следить. Если у вас с презентацией может работать только один пользователь, вы не используете HATEOAS и у вас вся логика на клиенте, то такое вполне допустимо. Вы, правда, все равно ресурс будет обновлять «порциями», а не целиком. Я бы не называл такой подход — REST-подходом, но опять же, при определенных условиях приемлемо.

Во 2-ом варианте, у вас на клиенте практически нет состояния, вы каждый раз обновляете его, посылая запрос на сервер и получаете список возможных действий. Например, что слайд, этот слайд можно скопировать, а другой нет. Здесь, появляется простота в масштабировании с точки зрения функциональности, есть всего лишь одно место для внесения изменений в бизнес-логике — это север.

На практике же, мне кажется лучше всего смотреть по предполагаем и реальным запросам пользователя, что часто запрашивают, а что нет и т. д. И уже в соответствие с этими знаниями «бить» ресурс на представления.

Как я понимаю WSDL — это статический перечень возможных действий. В HATEOAS же, мы получаем его динамически, при каждом запросе.
Еще ни разу не встречал его динамическим, но думаю это вполне можно реализовать. Я больше про сам принцип, что чем-то это все велосипедостроение напоминает. Да из браузера соапом не очень то удобно общаться с сервером але мiжна.

Как раз никто и не хочет изобретать велосипед, идея REST (www.ics.uci.edu/...ation/rest_arch_style.htm) существует с момента создания HTTP. Посмотрите имя первого автора в списке — www.w3.org/...ocols/rfc2616/rfc2616.txt.

Но люди зачем-то упорно изобретают велосипеды, которые абсолютно не приспособлены к работе на века.

Идея в том, что WWW доказал свою способность приспосабливаться и развиваться годами и нам как раз и не нужен велосипед, мы просто берем эту архитектуру за основу и также само строим общение между приложениями.

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

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

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

А если действие скажем по переводу денег доступно, но скажем не больше 10 баксов, а клиент пытается перевести 20? Можно конечно попытаться провернуть операцию и получить отказ от сервера, но тогда зачем создавать список доступных функций. Так же есть вариант бизнес правила, что деньги можно переводить, только если на счету не меньше 100 баксов, наверняка клиент попросит втулить задисейбленную кнопку с надписью, что вам не хватает денег на счету и пополните его плиз, сразу возникает вопрос, как в апи это будет выглядеть и как после пополнения клиент поймет, что теперь ему можно переводить деньги ? (из предположения, что все через апи и страничку мы не перегружаем)

Начну с конца, в крайнем случае в REST есть code-on-demand, то есть сервер может отдавать в виде кода, например, конкретно условие проверки. И есть более развитые форматы, чем просто список ссылок, например, github.com/kevinswiber/siren, которые могут включать ваш случай.

Тут ключевой момент, заключается в том, чтобы желательно клиент как можно чаще обновлял «состояние» или, вообще, его не хранил (состояние кэша контролируемое сервером — норм.).

Как один из вариантов реализации я бы отдать клиенту не только перечень ссылок, но и перечень недоступных действий с причинами. Здесь самое важное сохранить масштабируемость с точки зрения функциональности, не перенося бизнес-логику на клиент.

SOAP це протокол, а REST — ні. Не плутайте звичайний HTTP POST/PUT з терміном REST.

Ок. Чи можна сказати що SOAP це варіант реалізації REST в тому розумінні що описано у статті?
Мені здається, що так.

И да, и нет.

Есть такая модель — martinfowler.com/...hardsonMaturityModel.html. По ней, да, RPC — это первые уровни REST.

Реализации SOAP, которые я видел — это практически RPC и бонусы протокола.

Я бы хотел, чтобы все что не реализует HATEOAS, не называлось REST. Рой похоже об этом и говорит — roy.gbiv.com/...-must-be-hypertext-driven.

Переваги можуть з’явитися тільки тоді, коли буде озвучена кінцева мета, яку саме задачу треба вирішувати. А до того це все балачки з разряду «Хто сильніший, Брюс Лі чи Чак Норіс».
Великі файли можна завантажувати хоч через WS, немає особливо різниці. Треба визначитися що саме ви будуєте.

Це камасутра. Якщо питання в сексі як процесі — так, різниця колосальна. Якщо ж стоїть задача щось народити — то немає різниці в якій позі ви зробите концепцію.

эх, только я написал о том, что на доу не говорят о программировании;

Подписаться на комментарии