Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:
S>> Непроблема.В SOAP есть WS-ReliableMessaging, только в 1С нет поддержки этого протокола
S>Ага. Это называется "сначала мы создадим себе проблему, а потом будем прикручивать к ней неприлично дорогое решение".
Кстати а как из коробки повторная отправка письма решается на REST

Кстати это аналог реализации WS-ReliableMessaging из-за того, что 1С во многом ущербна

Здравствуйте, Serginio1, Вы писали:

S>Прикручивать приходится потому, что 1С не поддерживает все возможности. Да понятие неприлично дорогое для меня непонятно, это пшик (2-3 строчки)по сравнению с реально написанным кодом)
Этот пшик требует канала обратного вызова, что вообще говоря нонсенс в современном мире. То, что за вас кто-то написал тонну говнокода, который занимается нагреванием атмосферы, не отменяет технического убожества этого решения.
Надо смотреть в корень: единственным способом борьбы с отказами в распределённой системе является идемпотентность. REST, как подход, ставит эту идемпотентность на важное место и уделяет ей должное внимание. А SOAP начинает с отказа от идемпотентности, а потом придумывает себе адски сложные и дорогие в эксплуатации надстройки для возврата идемпотентности туда, где её не было.

S> Но вот в большинстве то используют SOAP потому, что его легко использовать.
Его легко использовать не потому, что он хороший, а потому, что к моменту выхода REST на сцену в SOAP уже были вбуханы миллиарды. Это как ездить в "киоск во дворе" на джипе: адски неэффективно "под капотом", но если у вас уже есть корпоративный джип, то вы таки будете им пользоваться даже для этого. А вот предлагать купить джип ради поездок за бутылкой пива на расстояние в 80 метров и обратно — это, простите, долбоклюйство.

Здравствуйте, Serginio1, Вы писали:
S> Кстати а как из коробки повторная отправка письма решается на REST
Почитайте вокруг — я в этом топике уже три раза разжевал пошаговый алгоритм "решения повторной отправки письма в REST"

Здравствуйте, dimgel, Вы писали:
D>А во-вторых, в порекомендованной A13X-ом книге (в начале, до подробностей в главе про тело ответа не добрался ещё) что-то говорилось про передачу ссылок на связанные документы в составе ответа. Т.е. с помощью ссылок (игнорируемых программным клиентом) и XSLT можно очень удобную фигню замутить, с полноценной навигацией.
Не, вот как раз игнорировать ничего не надо. Весь REST построен как раз на адресуемости объектов.
То есть вместо возврата непрозрачных идентификаторов, которые нужно как-то угадать куда вставлять, в ресте рекомендуется возвращать прямо честные URL, по которым можно сделать GET (ну, или другие глаголы).

Здравствуйте, -n1l-, Вы писали:
N>Если мы имеем дело с чем-то отличным от просмотра и/или изменения состояния, то REST нам и не нужен.
Совершенно верно. Вот только распределённые приложения без состояния малоинтересны. Как только появляются разделяемые данные — сразу появляется место для REST.
Придумать пример приложения, которое бы не нуждалось в передаче состояния, довольно сложно. Наверное, что-то вроде VoIP будет таким примером. Практически всё остальное — это распределённое состояние в том или ином виде.

Вы попробуйте придумать убедительный пример распределённого приложения, которое "отлично от просмотра и изменения состояния", а мы посмотрим, ляжет оно в REST или нет.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:

S>>Прикручивать приходится потому, что 1С не поддерживает все возможности. Да понятие неприлично дорогое для меня непонятно, это пшик (2-3 строчки)по сравнению с реально написанным кодом)
S>Этот пшик требует канала обратного вызова, что вообще говоря нонсенс в современном мире. То, что за вас кто-то написал тонну говнокода, который занимается нагреванием атмосферы, не отменяет технического убожества этого решения.
S>Надо смотреть в корень: единственным способом борьбы с отказами в распределённой системе является идемпотентность. REST, как подход, ставит эту идемпотентность на важное место и уделяет ей должное внимание. А SOAP начинает с отказа от идемпотентности, а потом придумывает себе адски сложные и дорогие в эксплуатации надстройки для возврата идемпотентности туда, где её не было.
Кстати а как Идемпотентность решена в RESTE?

S>> Но вот в большинстве то используют SOAP потому, что его легко использовать.
S>Его легко использовать не потому, что он хороший, а потому, что к моменту выхода REST на сцену в SOAP уже были вбуханы миллиарды. Это как ездить в "киоск во дворе" на джипе: адски неэффективно "под капотом", но если у вас уже есть корпоративный джип, то вы таки будете им пользоваться даже для этого. А вот предлагать купить джип ради поездок за бутылкой пива на расстояние в 80 метров и обратно — это, простите, долбоклюйство.
Да мне глубоко по барабану сколько и что весит пока это работает быстро и быстро разрабатывается. А вот когда будут тормоза я наплюю на сложность и я начну оптимизировать усложняя клиентскую часть.
Хотя сейчас занялся сайтописанием на ASP.Net mvc сервер сделать очень просто и на его основании сварганить клиента. Но вот с 1С это проблема, хотя там просто использовать оболочку из IReflect к сборкам.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:
S>> Кстати а как из коробки повторная отправка письма решается на REST
S>Почитайте вокруг — я в этом топике уже три раза разжевал пошаговый алгоритм "решения повторной отправки письма в REST"
Поиск не работает. Мне интересно как на физическом уровне. Понятно, что должно где то храниться ID запроса. И насколько это накладно для всех видов запросов.

Здравствуйте, Serginio1, Вы писали:
S> Кстати а как Идемпотентность решена в RESTE?
By design. Спецификация требует, чтобы глаголы PUT и DELETE были идемпотентными. Всё.

S> Да мне глубоко по барабану сколько и что весит пока это работает быстро и быстро разрабатывается. А вот когда будут тормоза я наплюю на сложность и я начну оптимизировать усложняя клиентскую часть.
Когда будут тормоза, будет уже поздно. Сейчас Microsoft заменяет SOAP-based API к Office 365 на REST-based Graph API. Разница в скорости видна невооружённым глазом.

Здравствуйте, Serginio1, Вы писали:
S> Поиск не работает.
Зачем поиск? В этой теме не так много постов.

S> Мне интересно как на физическом уровне. Понятно, что должно где то храниться ID запроса. И насколько это накладно для всех видов запросов.
Нет никакого ID запроса. У каждого объекта есть URL. Операции с объектом делятся на safe, idempotent, и операцию POST. Поэтому ничего "отдельно" хранить не надо.

Здравствуйте, Sinclair, Вы писали:

C>>Т.е. делаем запрос с уникальным ID и сохраняем ответ. При повторном запросе просто отдаём клиенту сохранённый уже ответ. Работает в большинстве случаев без какой-либо переделки протокола.
S>Это если вас внезапно осенило в тот момент, когда вы проектировали первую версию протокола. А если не осенило — упс, тупик. Вы не добавите conditional get в версии 2.0.
У меня был опыт добавления этой функциональности в готовый проект. Ничего, вполне справились — все изменения можно ограничить протокольным уровнем, не влияя на остальной код.

Конечно, у этого метода есть ограничения для highload и прочего, но далеко не всегда они критичны.

Здравствуйте, Sinclair, Вы писали:

S>> Кстати а как Идемпотентность решена в RESTE?
S>By design. Спецификация требует, чтобы глаголы PUT и DELETE были идемпотентными. Всё.
Ну то есть: "станьте ёжиками".

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, andyag, Вы писали:

A>>// Я вообще не фанат REST — просто смотрю на это всё со стороны и пытаюсь понять зачем этот REST нужен. Пока не понял. Субъективно — не нужен.
S>Чтобы понять, зачем он нужен, нужно получить негативный опыт на предшествующих технологиях. Когда вы упрётесь в то, что банальный conditional get требует редизайна RPC Endpoint, что означает "давайте лучше не будем, пока перформанс не вызовет эскалацию на уровне нашего директора", вы начнёте понимать, в чём преимущество подхода с safe methods. Когда вы столкнётесь с тем, что прикручивание идемпотентности тоже требует редизайна RPC Endpoint, причём обратно-несовместимым образом, что означает "давайте лучше не будем, пока количество сбоев не вызовет эскалацию на уровне нашего директора", вы поймёте, что REST всего лишь заставляет вас думать о реальности.
S>Да, приходится втискивать предметную область в непривычные рамки. Но на самом деле никакого mismatch нету — он появляется искусственно, когда сначала предметная область втискивается в рамки RPC. Просто эти рамки привычнее, и для втискивания в них не нужно делать почти никакого усилия. А вот потом, при "перевтискивании" приходится напрягать мозг, и возникает иллюзия какой-то неправильности.

S>Аналогом может являться представление звукового сигнала. Если привыкнуть представлять его в виде "отсчётов" — измерений амплитуды во времени, то переход к частотному представлению кажется совершенно противоестественным. Типа "ну и как я буду теперь отрезать первые 5 секунд от этой записи?" Зато в частотном представлении становятся удобными другие операции — например, фильтры низких/высоких частот.

Вы очень субъективно это воспринимаете. Есть дофига задач, где ценности, которые вы описываете — это не ценности, а рюшечки (как со стороны программирования, так и со стороны ценности для продукта). Если в вашей практике таких задач либо не было, либо было мало, безусловно вы станете ссылаться на 95% своего опыта (если вы, например, "старший архитектор интеграционных решений"). Но это только ваш опыт. Например, в том мире, где я живу "отправить письмо 2 раза" — это фигня — ну два ды, два. Ни холодно, ни жарко. Удалить одну сущность 2 раза, где второй раз упадёт с ошибкой — это тоже фигня: нажал "Ок", пошёл дальше. Затачивать API под вполне конкретный юзкейз, под одного-двух клиентов, вроде сайта и айфона, тоже нормально. REST это не "правильнее" и REST это не "лучше", REST это "типовое решение", которое можно применить, если у проекта есть задачи, которые можно решить с помощью этого типового решения. Если таких задач нет, REST будет просто "вытягиванием денег и времени".

Очень просто. То приложение в котором пользователи участвуют лишь косвенно и отслеживание состояния какой либо сущности не важно.
Так как email уже упомянули, я назову сервис (проверки)диагностики чего-нибудь например: скорости интернета, карты, показания датчиков online, какие-то расчеты.
Тут дело не в том, что типов проектов в которых REST не нужен — нет, а дело в том, что проектов по одному, двум типам в которых REST нужен — море.
Вот и создается впечатление,что REST основа всего и вся, что без нее никуда, что нужно постоянно в ней практиковаться и улучшать ее, но в итоге все равно припрется какой-нибудь умник, достанет из чулана xml-rpc, cgi, приправит это все каким-нибудь ruby, сделает gem и автогенерацию кода, напишет унылую статью на хабрахабр с заголовком "REST устарел встречайте бла-бла-бла..." или "Вы все еще используете REST?" или "Недостатки REST и как мы все с этим жили", потом это все обмусолится на какой-то еще более унылой конференции для корпораций в сфере айти. Далее в эту клоаку нырнут наивные работодатели и студентики, думая: "вау, новые технологии их надо изучать их нужно внедрять и развиваться", и в итоге все то, что решалось с помощью REST будет решаться с помощью вот той фигни.
Если я непонятно выразился, то объясню чуть популярнее. Какая вам разница, по какой методике изготавливают холодильник, в котором вы храните еду, если он исправно работает? Да никакой. Избыток технологий создал ситуацию в которой вы можете выбирать как, что и каким образом вы будете создавать.
Это делает сами споры о том, какая технология лучше просто абсурдными и бессмысленными. А факт попытки убеждения кого-либо, в том, что какая-то технология/архитектура/<что-то еще> лучше(просто лучше, не лучше подойдет для задачи, а просто лучше), можно интерпретировать, как симптом разложения головного мозга.

Здравствуйте, Sinclair,

А можно ещё вопрос?

PUT should be used to add a new resource to a store or update a resource. [...] POST should be used to create a new resource within a collection and execute controllers.

А почему добавление в store — PUT, а в collection — POST? Причём изменение ресурса, в т.ч. элемента коллекции — тоже PUT, то нафига тут POST вообще? Если дело в том, что PUT идемпотентный, то может у меня store допускает задвоения экземпляров?

Здравствуйте, dimgel, Вы писали:

D>

PUT should be used to add a new resource to a store or update a resource. [...] POST should be used to create a new resource within a collection and execute controllers.

D>А почему добавление в store — PUT, а в collection — POST? Причём изменение ресурса, в т.ч. элемента коллекции — тоже PUT, то нафига тут POST вообще? Если дело в том, что PUT идемпотентный, то может у меня store допускает задвоения экземпляров?
Заранее говорю — это всё очень ИМХО (хотя к ИМХО никакие "очень" и так не применимы).
Всё очень просто. Нужно аппелировать к здравой логике, а не к REST или RPC. Кто-бы что ни говорил, REST — и есть настоящий RPC, только с какими-то предзаданными правилами, которые никто не обязан соблюдать.
Защитникам REST (Sinclair) — заранее говорю, — мне идея нравится. Но, всё таки, для меня — это в большей степени чушь. Чушь не сколько в подходе, а сколько в виденных реализациях. 3-rd party товарищи умудряющтся отвечать NaN в JSON, что никак недопустимо. И это делают какие-то стандартные библиотеки, скорее всего около "стандартных" навроде JSON.NET. При чём тут REST — да ни при чём, в том то и дело.
Поэтому пока вы все тратите время на REST vs RPC — лучше потратьте его, на то, что бы соответствовать самими же любимым стандартам (если таковые имеются). Все valuable-peoples судя из всего топика отлично понимают как сделать надежную коммуникацию что в "REST" что в "RPC".
Но самое главное — *любой* запрос к HTTP серверу — уже по сути RPC. Более того, когда веб-сервер пишет в лог, что к нему обратились по GET — это уже "RPC", а не REST, ибо состояние очень даже меняется.
Логи не нужны для бизнеса? Это враки. Нужны (хотя видимо не всего подряд).
Поэтому в целом — спорите ни о чём.
Мне нравится REST, в том смысле, что и правда декларируется идемпотентность, или хотя бы о ней заставляет задуматься... ух сколько даже ново-разрабатываемых протоколов о таком не знают — сложно даже представить (на своём опыте видел). И вроде даже не "васи" делают.
Поэтому — суть не в REST-то. С хорошо спроектированным и документированным сервисом, REST-или-не-REST — всегда приятно работать. И обратное — если дока криволапая, и сервис такой же. Такова моя практика.

Здравствуйте, fddima, Вы писали:

D>>А почему добавление в store — PUT, а в collection — POST? Причём изменение ресурса, в т.ч. элемента коллекции — тоже PUT, то нафига тут POST вообще? Если дело в том, что PUT идемпотентный, то может у меня store допускает задвоения экземпляров?

F>Заранее говорю — это всё очень ИМХО (хотя к ИМХО никакие "очень" и так не применимы).

Да в общем-то я спрашивал про совершенно конкретный сугубо утилитарный момент, чтобы не сделать по-своему и не вляпаться в непонимание клиентских реализаций. Когда задаёшь вопрос "как на жаве сложить 2+2", ожидаешь ответ-таки по существу, а не в духе "жава — всего лишь один из языков, и не обязательно самый лучший, и сложение во всех языках есть". Про философию эту все и так более-менее в курсе.

Здравствуйте, Sinclair, Вы писали:

S>То есть вместо возврата непрозрачных идентификаторов, которые нужно как-то угадать куда вставлять, в ресте рекомендуется возвращать прямо честные URL, по которым можно сделать GET (ну, или другие глаголы).
Ну вот нынче писали REST API. Ну и @!@$*&@# этот REST. Скажем, несколько объектов в одной транзакции поменять нормально нельзя.

В теории есть метод PATCH, который делает частичные обновления, но знаю про него только я.

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

Здравствуйте, Cyberax, Вы писали:

C>Скажем, несколько объектов в одной транзакции поменять нормально нельзя.

Можно, сделав "POST /controller". Т.е. выйдя за рамки чистого REST.

C>В теории есть метод PATCH, который делает частичные обновления, но знаю про него только я.

Насколько я понимаю, никто не запрещает с клиента передавать в PUT не полный набор свойств. (Или ошибаюсь?)

C>Любой надёжный метод делается через полную задницу, в два шага (получить тикет, потом сделать запрос).

Про генерацию типа-GUID на клиенте я тут уже нагуглил: http://stackoverflow.com/a/2117523

А вообще, за всё надо платить, вот. Не знаю кто как, а лично я сербряной пули не ищу.

Здравствуйте, dimgel, Вы писали:

C>>Скажем, несколько объектов в одной транзакции поменять нормально нельзя.
D>Можно, сделав "POST /controller". Т.е. выйдя за рамки чистого REST.
Ну так у нас и RPC тоже поверх HTTP работает.

C>>В теории есть метод PATCH, который делает частичные обновления, но знаю про него только я.
D>Насколько я понимаю, никто не запрещает с клиента передавать в PUT не полный набор свойств. (Или ошибаюсь?)
Можно. Но в стандарте ничего не сказано про опциональные свойства, например.

C>>Любой надёжный метод делается через полную задницу, в два шага (получить тикет, потом сделать запрос).
D>Про генерацию типа-GUID на клиенте я тут уже нагуглил: http://stackoverflow.com/a/2117523
Небезопасно, если на сервере не проверять уникальность GUID-ов + предсказуемость.

Здравствуйте, dimgel, Вы писали:

D>Да в общем-то я спрашивал про совершенно конкретный сугубо утилитарный момент, чтобы не сделать по-своему и не вляпаться в непонимание клиентских реализаций. Когда задаёшь вопрос "как на жаве сложить 2+2", ожидаешь ответ-таки по существу, а не в духе "жава — всего лишь один из языков, и не обязательно самый лучший, и сложение во всех языках есть". Про философию эту все и так более-менее в курсе.
Про философию тут то в курсе все, но, я вот вляпался в непонимание сервером JSON. Стоит ли мне рассчитывать, что сервер в действительности удовлетворяет допустим, свойству идемпотентности некоторых методов? Выглядит как REST. И что мне это даёт? Да ничего не даёт. Он всё так же может, а может и нет.
Я всегда думал о вызове методов HTTP сервера как о RPC, и буду думать так. И потому, что это ни, что иное как RPC и есть. RPC кстати не обязан ходить по какому-то определённому протоколу.
Я в большей степени по этому и удивлён каким-то этим спорам, когда сравнивается одна фундаментальная вещь (RPC) с модно-конкретной (REST).

PS: POST — есть Create. PUT — есть Update. Реализация идемпотентности к POST (а она нужна) — зависит полностью от тебя, что бы там умы не говорили.