Добрался вот, читаю "O'Reilly RESTful Web Services", ещё тыщу лет назад посоветованную кажется gandjustas'ом. И вот что я хочу сказать:
1. Воды — просто фантастическое количество. Тянет на книгу рекордов Гиннесса. Прочитано: 10%; полезного найдено: 1 предложение. А именно (привожу примерно): "RPC выставляет наружу алгоритмы, REST — данные". Сдаётся мне, остальные 90% можно не читать. Рекомендовать такую, прости господи, литературу — это чистый садизм.
2. Из процитированного предложения следует одна простая вещь: с помощью REST можно отредактировать запись в базе, но нельзя, к примеру, отправить email. Нельзя сделать ничего такого, что не является чтением/записью данных.
3. То есть, если нам надо отправить email, мы либо пуляем RPC поверх HTTP (раз mismatch), либо прикидываемся, что "отправка email" — это типа разновидность записи данных такая (два mismatch). Куда не плюнь — всюду mismatch.
4. Вывод: вот и границы применимости этого вашего REST-а нарисовались: помойки данных, где любые операции, отличные от чтения/записи даных, идут как неявные побочные эффекты.
Re: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
D>3. То есть, если нам надо отправить email, мы либо пуляем RPC поверх HTTP (раз mismatch), либо прикидываемся, что "отправка email" — это типа разновидность записи данных такая (два mismatch). Куда не плюнь — всюду mismatch.
Да ну брось. Пусть REST выставляет очередь на отправку емайлов. Операция PUT — помещает в очередь. Никакого мисматча
Re: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
был.
D>Добрался вот, читаю "O'Reilly RESTful Web Services", ещё тыщу лет назад посоветованную кажется gandjustas'ом. И вот что я хочу сказать:
D>1. Воды — просто фантастическое количество. Тянет на книгу рекордов Гиннесса. Прочитано: 10%; полезного найдено: 1 предложение. А именно (привожу примерно): "RPC выставляет наружу алгоритмы, REST — данные". Сдаётся мне, остальные 90% можно не читать. Рекомендовать такую, прости господи, литературу — это чистый садизм.
Так это у любой книги по технологиям так.
D>2. Из процитированного предложения следует одна простая вещь: с помощью REST можно отредактировать запись в базе, но нельзя, к примеру, отправить email. Нельзя сделать ничего такого, что не является чтением/записью данных.
D>3. То есть, если нам надо отправить email, мы либо пуляем RPC поверх HTTP (раз mismatch), либо прикидываемся, что "отправка email" — это типа разновидность записи данных такая (два mismatch). Куда не плюнь — всюду mismatch.
D>4. Вывод: вот и границы применимости этого вашего REST-а нарисовались: помойки данных, где любые операции, отличные от чтения/записи даных, идут как неявные побочные эффекты.
Вроде весь пользовательский веб (блоги, соц. сети) в эту модель удачно укладывается.
Бизнесу rpc поудобнее будет.
Кодом людям нужно помогать!
Re: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, dimgel, Вы писали:
D>А может и не давненько, да я пропустил.
D>Добрался вот, читаю "O'Reilly RESTful Web Services", ещё тыщу лет назад посоветованную кажется gandjustas'ом. И вот что я хочу сказать:
D>1. Воды — просто фантастическое количество. Тянет на книгу рекордов Гиннесса. Прочитано: 10%; полезного найдено: 1 предложение. А именно (привожу примерно): "RPC выставляет наружу алгоритмы, REST — данные". Сдаётся мне, остальные 90% можно не читать. Рекомендовать такую, прости господи, литературу — это чистый садизм.
Мне больше понравилась <b>эта книга</b> (или мы говорим об одной и той же)?
D>2. Из процитированного предложения следует одна простая вещь: с помощью REST можно отредактировать запись в базе, но нельзя, к примеру, отправить email. Нельзя сделать ничего такого, что не является чтением/записью данных.
D>3. То есть, если нам надо отправить email, мы либо пуляем RPC поверх HTTP (раз mismatch), либо прикидываемся, что "отправка email" — это типа разновидность записи данных такая (два mismatch). Куда не плюнь — всюду mismatch.
Рест вполне подходит для таких операций. Цитирую
Rule: POST must be used to create a new resource in a collection
... skipped ...
Rule: POST must be used to execute controllers
Clients use the POST method to invoke the function-oriented controller resources. A POST request message may include both headers and a body as inputs to a controller resource’s function.
HTTP designates POST as semantically open-ended. It allows the method to take any action, regardless of its repeatability or side effects. This makes POST the clear choice to be paired with the equally unrestricted controller resources.
Our REST API designs use POST, along with a targeted controller resource, to trigger all operations that cannot be intuitively mapped to one of the other core HTTP methods. In other words, the POST method should not be used to get, store, or delete resources —HTTP already provides specific methods for each of those functions.
HTTP calls the POST request method unsafe and non-idempotent, which means that its outcome is unpredictable and not guaranteed to be repeatable without potentially un- desirable side effects. For example, a resubmitted web form that uses POST might run the risk of double billing a user’s credit card. Controller resources trade a degree of transparency and robustness for the sake of flexibility.
The example below demonstrates how a controller can be executed using the POST request method:
POST /alerts/245743/resend
This is the second use of POST in the design of REST APIs. This use case resembles the fairly common concept of a runtime system’s “PostMessage” mechanism, which allows functions to be invoked across some sort of boundary.
— Chapter 3: Interaction Design with HTTP
Таким образом следуя рекомендациям вполне можно сделать и отправку писем и все остальное подобное, имеющее побочные эффекты
D>4. Вывод: вот и границы применимости этого вашего REST-а нарисовались: помойки данных, где любые операции, отличные от чтения/записи даных, идут как неявные побочные эффекты.
Re: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, dimgel, Вы писали:
D>А может и не давненько, да я пропустил.
D>Добрался вот, читаю "O'Reilly RESTful Web Services", ещё тыщу лет назад посоветованную кажется gandjustas'ом. И вот что я хочу сказать:
D>1. Воды — просто фантастическое количество. Тянет на книгу рекордов Гиннесса. Прочитано: 10%; полезного найдено: 1 предложение. А именно (привожу примерно): "RPC выставляет наружу алгоритмы, REST — данные". Сдаётся мне, остальные 90% можно не читать. Рекомендовать такую, прости господи, литературу — это чистый садизм.
Не читал, но осуждаю.
D>2. Из процитированного предложения следует одна простая вещь: с помощью REST можно отредактировать запись в базе, но нельзя, к примеру, отправить email. Нельзя сделать ничего такого, что не является чтением/записью данных.
Видимо, плохая книжка, раз сформировалось такое восприятие. REST в этом своём аспекте требует перехода из базиса действий в базис существительных. Т.е. надо просто немного жерезжопнее думать: вместо "отправить письмо" — "положить письмо в стопку исходящих". Вроде одно и то же, но уже
POST /outbox
{
"message": "hi there"
}
Начинает выглядеть чуть осмысленнее. Но это вообще не самое то, что REST.
D>3. То есть, если нам надо отправить email, мы либо пуляем RPC поверх HTTP (раз mismatch), либо прикидываемся, что "отправка email" — это типа разновидность записи данных такая (два mismatch). Куда не плюнь — всюду mismatch.
Это примерно такой же mismatch, как вообще говорить "отправить письмо". Там ведь после вашего запроса (будь то RPC или REST) не напишет никто письмо от руки, не пойдёт на почту пооблизывать марки. То что вы делаете — это в любом случае — отправить пачку байтов куда-то там. Просто чтобы крыша не поехала, вы мыслите на другом уровне абстракции. Что вас заставляет думать терминами "отправить письмо", а не "положить письмо в исходящие"?
D>4. Вывод: вот и границы применимости этого вашего REST-а нарисовались: помойки данных, где любые операции, отличные от чтения/записи даных, идут как неявные побочные эффекты.
Нифига. Все операции условно можно разделить на порождающие сущности, удаляющие сущности и изменяющие состояние сущностей. Если с первым и вторым всё довольно тривиально, последнее — более интересно. Один RPC запрос, как правило, изменяет состояние какой-то одной _логической_ сущности. Технически сущность может быть очень сложной — десятки таблиц в базе, файлы какие-то, но _сама логическая сущность_, над которой производится операция — ровно одна. В результате такого запроса у сущности изменяется какой-то аспект состояния. Вот REST предлагает оформлять API именно в виде таких логических сущностей. Т.е. снаружи оно реально будет выглядеть как тупой CRUD для помойки данных, но внутри может этим и не являться (но в большинстве случаев вы правы — да).
Т.е. вместо того, чтобы говорить, например, ConfirmOrder, вы берёте этот самый Order:
{
"self": "http://porn/123",
"confirmed": false
}
выставляете ему confirmed: true и отправляете серверу. На основании диффа между состоянием этого Order на сервере и новым состоянием, которое вы прислали, сервер может (если хочет) понять что за операция случилась. Вот эта самая операция — это тот самый RPC, который вам так нравится. Как только операция "распознана", можно творить любой хаос, как если бы у нас действительно был RPC и пользователь дёрнул ConfirmOrder напрямую. Ни в коем случае не говорю, что именно так стоит эту штуку реализовать — это просто переходная модель мира.
Следующий этап после "переходной модели" — не думать о "действиях" вообще, а думать только о просьбах "что-то поменять" у сущности. Т.е. вместо задавания себе вопроса "что я буду делать в ConfirmOrder?" задавать себе вопрос "что я буду делать, когда кто-то хочет поменять подтверждённость заказа?". Этот подход позволяет проще относиться к ситуациям, когда у сущности предлагается поменять не один аттрибут, а несколько за один раз.
// Я вообще не фанат REST — просто смотрю на это всё со стороны и пытаюсь понять зачем этот REST нужен. Пока не понял. Субъективно — не нужен.
Re[2]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, avpavlov, Вы писали:
A>Да ну брось. Пусть REST выставляет очередь на отправку емайлов. Операция PUT — помещает в очередь. Никакого мисматча
Как идемпотентность этого PUT обеспечивать будешь? Если он выдан дважды, может это два одинаковых письма отправить надо?
Re[2]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, A13x, Вы писали:
A>Мне больше понравилась <b>эта книга</b> (или мы говорим об одной и той же)?
Нет, это другая, и тут воды нет. Спасибо.
A>
A>Rule: POST must be used to execute controllers
...
A>HTTP calls the POST request method unsafe and non-idempotent, which means that its outcome is unpredictable and not guaranteed to be repeatable without potentially un- desirable side effects. For example, a resubmitted web form that uses POST might run the risk of double billing a user’s credit card. Controller resources trade a degree of transparency and robustness for the sake of flexibility.s functions to be invoked across some sort of boundary.
A>Таким образом следуя рекомендациям вполне можно сделать и отправку писем и все остальное подобное, имеющее побочные эффекты
Ага... Вот она, реальная жизнь, а не та красивая концептуальщина, про которую тут отдельные товарищи заливали. Но дочитаю-ка сначала. Тут и страниц поменьше в 4 раза будет, и смысла побольше.
Re[2]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
D>>3. То есть, если нам надо отправить email, мы либо пуляем RPC поверх HTTP (раз mismatch), либо прикидываемся, что "отправка email" — это типа разновидность записи данных такая (два mismatch). Куда не плюнь — всюду mismatch.
A>Да ну брось. Пусть REST выставляет очередь на отправку емайлов. Операция PUT — помещает в очередь. Никакого мисматча
А можно на примере этой отправки емайлов объяснить — какое преимущество мы получаем от отправки емайла в стиле REST? Недостаток я уже понял, надо думать думу, как вместить тривиальную операцию в ограниченную предметную область. На первый взгляд совершенно ненужная дума, отнимающая время и не дающая никакого преимущества перед лобовой реализовацией post /sendemail { "message": "hello" }.
Re[3]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, vsb, Вы писали:
vsb>А можно на примере этой отправки емайлов объяснить — какое преимущество мы получаем от отправки емайла в стиле REST? Недостаток я уже понял, надо думать думу, как вместить тривиальную операцию в ограниченную предметную область. На первый взгляд совершенно ненужная дума, отнимающая время и не дающая никакого преимущества перед лобовой реализовацией post /sendemail { "message": "hello" }.
Обще-теоретический ответ, очевидно, такой: подгонкой своего API под архитектуру веба ты получаешь все плюшки этой архитектуры, в т.ч. масштабируемость и не-велосипедность (принципы архитектуры хорошо перечислены в посоветованной чуть выше
книге.). А сугубо практически, если следовать рекомендации и завести отдельный поддомен api, то пока что неясно, чем плох /sendmail. Может и ничем, отдельный архетип ресурса — Controller — на это уже намекает (впрочем, тогда уж по идее лучше controller/method, т.е. mailer/send), читаю дальше.
Re[4]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, dimgel, Вы писали:
D>отдельный архетип ресурса — Controller — на это уже намекает (впрочем, тогда уж по идее лучше controller/method, т.е. mailer/send), читаю дальше.
А дальше — странное. Предлагается URL такой: /message/ID/send (в книге — "POST /alerts/245743/resend"). Т.е. rich domain model по сути. Не согласная я.
Re[3]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, dimgel, Вы писали: D>Как идемпотентность этого PUT обеспечивать будешь? Если он выдан дважды, может это два одинаковых письма отправить надо?
Вот как раз в отличие от корявого RPC, то, что вы задались этим вопросом сейчас (а не через 6 месяцев эксплуатации), гарантирует вашим клиентам спокойный ночной сон.
Есть два очевидных сценария:
1. Client-generated IDs. То есть я генерирую GUID и использую его при постановке в очередь.
2. Server-generated tickets. To есть я запрашиваю ID у сервера при помощи POST на соответствующий ресурс, а потом использую его в PUT.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, vsb, Вы писали: vsb>А можно на примере этой отправки емайлов объяснить — какое преимущество мы получаем от отправки емайла в стиле REST?
Очень простое — предсказуемость работы в случае сбоев. Если RPC вызов "SendMail" упал по таймауту или вернул 5хх, то нет никакого способа узнать, было ли письмо таки отправлено. Retry, возможно, приведёт к дублированию (и я раз в иногда получаю пару десятков писем от залипшего клиента), а игнор, возможно, приведёт к потере. REST позволяет мне Retry-ить в случае сомнений до получения либо 2хх либо 4хх.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, andyag, Вы писали:
A>// Я вообще не фанат REST — просто смотрю на это всё со стороны и пытаюсь понять зачем этот REST нужен. Пока не понял. Субъективно — не нужен.
Чтобы понять, зачем он нужен, нужно получить негативный опыт на предшествующих технологиях. Когда вы упрётесь в то, что банальный conditional get требует редизайна RPC Endpoint, что означает "давайте лучше не будем, пока перформанс не вызовет эскалацию на уровне нашего директора", вы начнёте понимать, в чём преимущество подхода с safe methods. Когда вы столкнётесь с тем, что прикручивание идемпотентности тоже требует редизайна RPC Endpoint, причём обратно-несовместимым образом, что означает "давайте лучше не будем, пока количество сбоев не вызовет эскалацию на уровне нашего директора", вы поймёте, что REST всего лишь заставляет вас думать о реальности.
Да, приходится втискивать предметную область в непривычные рамки. Но на самом деле никакого mismatch нету — он появляется искусственно, когда сначала предметная область втискивается в рамки RPC. Просто эти рамки привычнее, и для втискивания в них не нужно делать почти никакого усилия. А вот потом, при "перевтискивании" приходится напрягать мозг, и возникает иллюзия какой-то неправильности.
Аналогом может являться представление звукового сигнала. Если привыкнуть представлять его в виде "отсчётов" — измерений амплитуды во времени, то переход к частотному представлению кажется совершенно противоестественным. Типа "ну и как я буду теперь отрезать первые 5 секунд от этой записи?" Зато в частотном представлении становятся удобными другие операции — например, фильтры низких/высоких частот.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, Sinclair, Вы писали:
D>>Как идемпотентность этого PUT обеспечивать будешь? Если он выдан дважды, может это два одинаковых письма отправить надо?
S>Вот как раз в отличие от корявого RPC, то, что вы задались этим вопросом сейчас (а не через 6 месяцев эксплуатации), гарантирует вашим клиентам спокойный ночной сон. S>Есть два очевидных сценария: S>1. Client-generated IDs. То есть я генерирую GUID и использую его при постановке в очередь. S>2. Server-generated tickets. To есть я запрашиваю ID у сервера при помощи POST на соответствующий ресурс, а потом использую его в PUT.
Хоть это и будет "опять двадцать пять" для продолжения беседы, но повторю сказанное ещё в прошлый срач, в котором я участвовал: генерить ID-ы я точно так же и в RPC могу, both корявый RPC and не-корявый REST тут ортогональны. То есть, (опять-таки повторяю тогдашний тезис) "идемпотентость надо обеспечивать руками". По крайней мере для Controller и для Create.
Re[3]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, Sinclair, Вы писали:
S>Да, приходится втискивать предметную область в непривычные рамки. Но на самом деле никакого mismatch нету — он появляется искусственно, когда сначала предметная область втискивается в рамки RPC. Просто эти рамки привычнее, и для втискивания в них не нужно делать почти никакого усилия. А вот потом, при "перевтискивании" приходится напрягать мозг, и возникает иллюзия какой-то неправильности.
Любопытно и доля истины ощущается. Но ограниченность множества глаголов — объективный факт. (Я ХЗ как ты относишься к типу ресурса "контроллер", мне же он кажется натягиванием презерватива на глобус — отход от концептуально правильного REST-а, пригодного в чистом виде — повторюсь — только для ресурсопомоек, в угоду суровой правде жизни.)
Re: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, dimgel, Вы писали:
D>А может и не давненько, да я пропустил.
D>Добрался вот, читаю "O'Reilly RESTful Web Services", ещё тыщу лет назад посоветованную кажется gandjustas'ом. И вот что я хочу сказать:
D>1. Воды — просто фантастическое количество. Тянет на книгу рекордов Гиннесса. Прочитано: 10%; полезного найдено: 1 предложение. А именно (привожу примерно): "RPC выставляет наружу алгоритмы, REST — данные". Сдаётся мне, остальные 90% можно не читать. Рекомендовать такую, прости господи, литературу — это чистый садизм.
Без этой литературы вы, к сожалению, ничего не поймёте. Чтобы эта фраза обрела смысл, нужно налить много воды: несколько раз объяснить простые, вроде бы, вещи; привести несколько десятков примеров. И только после этого в голове может что-то щёлкнуть, и детальки встанут на свои места.
D>2. Из процитированного предложения следует одна простая вещь: с помощью REST можно отредактировать запись в базе, но нельзя, к примеру, отправить email. Нельзя сделать ничего такого, что не является чтением/записью данных.
Вот видите — вы уже начали неправильно понимать. Нет такого следствия. Это как считать "с помощью RPC можно отправить email, но нельзя, к примеру, отредактировать запись в базе". Выразительность и в REST и в RPC совершенно одинакова. Просто в REST больше внимания уделяется опциональным и непопулярным в RPC вещам, что обычно приводит к более высокому качеству протоколов, спроектированных через REST.
D>4. Вывод: вот и границы применимости этого вашего REST-а нарисовались: помойки данных, где любые операции, отличные от чтения/записи даных, идут как неявные побочные эффекты.
Всё наоборот: границы применимости RPC — это бесконечно широкие и бесконечно надёжные каналы связи между клиентом и сервером. Потому что RPC не предлагает никаких возможностей для оптимизации запросов и восстановления после сбоев. А возможности, вшитые в HTTP с прошлого века, требуют приделывания смешных велосипедов. Вот, недавно обнаружил — Windows PowerShell for Windows Azure AD (естественно) внутри использует классический SOAP; при этом нагрузка балансируется на три разных сервера, и делается это при помощи бросания специального исключения "RedirectResponseFault". Пацаны молодцы — всего в нескольких килобайтах кода они прикрутили поддержку собственного аналога статуса 307.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, dimgel, Вы писали:
A>>Да ну брось. Пусть REST выставляет очередь на отправку емайлов. Операция PUT — помещает в очередь. Никакого мисматча D>Как идемпотентность этого PUT обеспечивать будешь? Если он выдан дважды, может это два одинаковых письма отправить надо?
Отправка письма с защитой от потерь и дупов — это всегда проблема, если нет установленного доверия между клиентом и сервером. Как правило, сервер должен выбирать, доверять ли произвольному клиенту; реже клиент перебирает серверы в поисках доверенного. Если клиентов много и доверие к ним неизвестно, то механизмы защиты будут слишком дороги и будут допускать DDoS. Но если их немного и они адекватно аутентифицированы, то проблемы нет.
Например, на FTN транспорте проблема дупов решалась хуже, чем на UUCP, потому что на FTN в общем случае линки недоверенные (кто угодно может позвонить), а на UUCP — преднастроенные. Делалось это на UUCP так: каждое письмо отправляется в виде заявки типа rmail (rnews, etc.), а заявка состоит из D-файла и X-файла. D-файл всегда передаётся вперёд X-файла. Транспорт обеспечивает докачку (не все протоколы) и сохранение промежуточных файлов. Цена за надёжность — хранение временных файлов отправителя у приёмника между сеансами связи.
Такой же механизм переводится тривиально на REST, но — с подпоркой от клиента. А именно:
1. Делается PUT с выбранным id (кто генерирует — неважно, лишь бы случайно). Если не получилось, повторяется. Письмо при этом не отправляется, а только лежит в выходной очереди клиента на сервере. Клиент запоминает id и факт завершения этого PUT в своих локальных данных. Можно организовать докачку, если оно большое.
2. Делается сигнал посылки письма из уже сохранённого на сервере. Вот тут это вообще-то не GET и не PUT REST позволяет назначать свои методы, придумаем какой-нибудь SEND. Главное — опять же возможность повторить его несколько раз и/или потерять промежуточный ответ без побочных эффектов. Сервер должен понять, что есть заказ отправить, и сказать об этом. Отказ типа "такого id нет" аналогичен "уже отправили", но можно делать сохранение отправленных id на несколько дней, чтобы давать более конкретный ответ.
Повторюсь, что проблема не в REST, проблема в исходной задаче. Она в любом случае решается комбинацией контролей элементарной передачи, сквозной доставки, переповторов и таймаутов.
The God is real, unless declared integer.
Re[2]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, Sinclair, Вы писали:
S>Без этой литературы вы, к сожалению, ничего не поймёте. Чтобы эта фраза обрела смысл, нужно налить много воды: несколько раз объяснить простые, вроде бы, вещи; привести несколько десятков примеров.
Да-да, про классификации животных по ДНК и внешнему виду. Не делайте мне смешно, всякому беспеределу должен быть предел. Я было подумал, что эта книга наверное для выпускников американских школ писалась, но они её тоже не осилят — заснут.
S>Вот видите — вы уже начали неправильно понимать. Нет такого следствия.
Значит, либо исходное утверждение не верно, либо же, как я и написал, это paradigm mismatch, в данном случае — натягивание термина "ресурс" на то, что ресурсом не является: на глаголы.
S>Выразительность и в REST и в RPC совершенно одинакова.
Ага, даже идемпотентность приходится и там, и там руками обеспечивать. :-P
S>Просто в REST больше внимания уделяется опциональным и непопулярным в RPC вещам, что обычно приводит к более высокому качеству протоколов, спроектированных через REST. S>Всё наоборот: границы применимости RPC — это бесконечно широкие и бесконечно надёжные каналы связи между клиентом и сервером. Потому что RPC не предлагает никаких возможностей для оптимизации запросов и восстановления после сбоев.
Вот это собственно и есть единственное преимущество REST: что кое-какую работёнку за тебя уже сделали, и качество этой работёнки себя уже зарекомендовало, так что не надо изобретать велосипедное решение по обеспечению надёжности и масштабируемости.
