Здравствуйте, dimgel, Вы писали: D>Любопытно и доля истины ощущается. Но ограниченность множества глаголов — объективный факт. (Я ХЗ как ты относишься к типу ресурса "контроллер", мне же он кажется натягиванием презерватива на глобус — отход от концептуально правильного REST-а, пригодного в чистом виде — повторюсь — только для ресурсопомоек, в угоду суровой правде жизни.)
Спор беспредметен. Во всех предыдущих инкарнациях, REST выигрывал у RPC на его же поле. Я по-прежнему открыт к дискуссии в формате "вот схема RPC API, и по-моему это плохо воспроизводится в REST". В ответ на что я предъявляю схему REST-сервиса, который делает то же самое, плюс решает пару проблем, о которых автор RPC по наивности не подумал. Либо я соглашаюсь, что да, таки в данном случае RPC лучше, и мы наконец-то имеем хоть один пример, где RPC выигрывает.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, Sinclair, Вы писали:
S>Спор беспредметен. [...] Я по-прежнему открыт к дискуссии в формате
Скажи лучше, как тебе такая идейка для отладки RESTful-сервиса: отдавать XML с <?xls-stylesheet?>, чтобы можно было прям настоящее живое API из-под браузера глазками-ручками тестировать. (Вообще, я сильно больше JSON люблю, но тут мне кажется может получиться забавно.)
Re[4]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vsb, Вы писали: vsb>>А можно на примере этой отправки емайлов объяснить — какое преимущество мы получаем от отправки емайла в стиле REST? S>Очень простое — предсказуемость работы в случае сбоев. Если RPC вызов "SendMail" упал по таймауту или вернул 5хх, то нет никакого способа узнать, было ли письмо таки отправлено. Retry, возможно, приведёт к дублированию (и я раз в иногда получаю пару десятков писем от залипшего клиента), а игнор, возможно, приведёт к потере. REST позволяет мне Retry-ить в случае сомнений до получения либо 2хх либо 4хх.
Почему? Если ты ответа не получил, то так, же как и с REST отправляешь с письмом ГУИД. У меня так на SOAP прекрасно работает.
и солнце б утром не вставало, когда бы не было меня
Re[3]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, Sinclair, Вы писали:
S>Чтобы понять, зачем он нужен, нужно получить негативный опыт на предшествующих технологиях. Когда вы упрётесь в то, что банальный conditional get требует редизайна RPC Endpoint, что означает "давайте лучше не будем, пока перформанс не вызовет эскалацию на уровне нашего директора", вы начнёте понимать, в чём преимущество подхода с safe methods. Когда вы столкнётесь с тем, что прикручивание идемпотентности тоже требует редизайна RPC Endpoint, причём обратно-несовместимым образом
Необязательно. Мы добавляли идемпотентность просто на уровень RPC-протокола. Не так уж и сложно, если можно хранить ответы.
Т.е. делаем запрос с уникальным ID и сохраняем ответ. При повторном запросе просто отдаём клиенту сохранённый уже ответ. Работает в большинстве случаев без какой-либо переделки протокола.
Sapienti sat!
Re[3]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, avpavlov, Вы писали:
D>>>3. То есть, если нам надо отправить email, мы либо пуляем RPC поверх HTTP (раз mismatch), либо прикидываемся, что "отправка email" — это типа разновидность записи данных такая (два mismatch). Куда не плюнь — всюду mismatch.
A>>Да ну брось. Пусть REST выставляет очередь на отправку емайлов. Операция PUT — помещает в очередь. Никакого мисматча
vsb>А можно на примере этой отправки емайлов объяснить — какое преимущество мы получаем от отправки емайла в стиле REST?
Отсутствие бессоницы из-за paradigm mismatch. Если бессоницы нет и не было, то можно не париться и использовать любой подход
Re[3]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, avpavlov, Вы писали:
A>>Да ну брось. Пусть REST выставляет очередь на отправку емайлов. Операция PUT — помещает в очередь. Никакого мисматча
D>Как идемпотентность этого PUT обеспечивать будешь? Если он выдан дважды, может это два одинаковых письма отправить надо?
Это пусть клиент парится. Если я ему вернул ОК, а он повторно отправляет — значит так и надо. Если я ему вернул ошибку, то пусть анализирует какую именно и отправляет повторно, или внимательно набирает УРЛ или ещё чего.
Re[4]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, avpavlov, Вы писали:
A>>>Да ну брось. Пусть REST выставляет очередь на отправку емайлов. Операция PUT — помещает в очередь. Никакого мисматча
D>>Как идемпотентность этого PUT обеспечивать будешь? Если он выдан дважды, может это два одинаковых письма отправить надо?
A>Это пусть клиент парится. Если я ему вернул ОК, а он повторно отправляет — значит так и надо. Если я ему вернул ошибку, то пусть анализирует какую именно и отправляет повторно, или внимательно набирает УРЛ или ещё чего.
Вы отвечаете, даже не попытавшись понять суть проблемы. Пусть передача тела по PUT завершилась, а перед получением OK от сервера порвалась связь. Как клиент поймёт, передавать заново или нет?
The God is real, unless declared integer.
Re[6]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, dimgel, Вы писали:
D>Скажи лучше, как тебе такая идейка для отладки RESTful-сервиса: отдавать XML с <?xls-stylesheet?>, чтобы можно было прям настоящее живое API из-под браузера глазками-ручками тестировать. (Вообще, я сильно больше JSON люблю, но тут мне кажется может получиться забавно.)
Отличная идейка. И это никак не противоречит JSON, т.к. руками данные сейчас всё равно никто не клеит, а при наличии инфраструктуры научить сервис использовать разные сериализаторы в зависимости от .html/.xml/.js в конце урла не стоит почти ничего.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, Cyberax, Вы писали: C>Необязательно. Мы добавляли идемпотентность просто на уровень RPC-протокола. Не так уж и сложно, если можно хранить ответы.
C>Т.е. делаем запрос с уникальным ID и сохраняем ответ. При повторном запросе просто отдаём клиенту сохранённый уже ответ. Работает в большинстве случаев без какой-либо переделки протокола.
Это если вас внезапно осенило в тот момент, когда вы проектировали первую версию протокола. А если не осенило — упс, тупик. Вы не добавите conditional get в версии 2.0.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, Serginio1, Вы писали: S> Почему? Если ты ответа не получил, то так, же как и с REST отправляешь с письмом ГУИД. У меня так на SOAP прекрасно работает.
Это по факту означает, что вы изобрели свой собственный REST, только без его преимуществ — в частности, в REST идемпотентность PUT известна ещё до начала разработки протокола, а у вас нужно руками документировать идемпотентность вашего метода.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
N>Вы отвечаете, даже не попытавшись понять суть проблемы. Пусть передача тела по PUT завершилась, а перед получением OK от сервера порвалась связь. Как клиент поймёт, передавать заново или нет?
Почему она только для РЕСТ "нерешаема"?
Re[6]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, avpavlov, Вы писали:
N>>Вы отвечаете, даже не попытавшись понять суть проблемы. Пусть передача тела по PUT завершилась, а перед получением OK от сервера порвалась связь. Как клиент поймёт, передавать заново или нет? A>Почему она только для РЕСТ "нерешаема"?
Она решаема. С разной степенью надёжности в зависимости от применённых средств. Но Ваш метод точно её не решит.
The God is real, unless declared integer.
Re[7]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, dimgel, Вы писали:
D>>Скажи лучше, как тебе такая идейка для отладки RESTful-сервиса: отдавать XML с <?xls-stylesheet?>, чтобы можно было прям настоящее живое API из-под браузера глазками-ручками тестировать. (Вообще, я сильно больше JSON люблю, но тут мне кажется может получиться забавно.) S>Отличная идейка. И это никак не противоречит JSON, т.к. руками данные сейчас всё равно никто не клеит, а при наличии инфраструктуры научить сервис использовать разные сериализаторы в зависимости от .html/.xml/.js в конце урла не стоит почти ничего.
Ребят, обожите. Если я правильно понял ваши идеи, то сейчас этих тестировщиков REST API
навалом. Есть плагины для фф и для хрома. Fiddler опять же...
В чем прикол?
Кодом людям нужно помогать!
Re[8]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, Sharov, Вы писали: S>Ребят, обожите. Если я правильно понял ваши идеи, то сейчас этих тестировщиков REST API S>навалом. Есть плагины для фф и для хрома. Fiddler опять же... S>В чем прикол?
Прикол в том, что быстрее всего просто зайти браузером в URL и "пощупать руками", и "посмотреть глазами".
Вот, например, http://apscatalog.com/2.0/
Это API нашего каталога — он полностью browser discoverable. Но выглядит страшненько без стилей. Лучше делать view source, но это неудобно — во view source нет навигации по кликам.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали: S>> Почему? Если ты ответа не получил, то так, же как и с REST отправляешь с письмом ГУИД. У меня так на SOAP прекрасно работает. S>Это по факту означает, что вы изобрели свой собственный REST, только без его преимуществ — в частности, в REST идемпотентность PUT известна ещё до начала разработки протокола, а у вас нужно руками документировать идемпотентность вашего метода.
Непроблема.В SOAP есть WS-ReliableMessaging, только в 1С нет поддержки этого протокола Зато у RESTа куча недостатков перед SOAP. Кстати ту в 1С http://v8.1c.ru/o7/201312rest/index.htm смотрят в сторону ODATA
В качестве протокола доступа платформа использует протокол OData версии 3.0. Это открытый веб-протокол для запроса и обновления данных. Он позволяет оперировать данными, используя в качестве запросов HTTP-команды. Получать ответы можно в различных форматах, но пока мы поддерживаем только работу с данными в формате Atom/XML.
В платформе мы реализовали только серверную часть REST сервисов. То есть прикладное решение может автоматически поставлять свою функциональность через REST сервисы. Для взаимодействия со сторонними REST сервисами из 1С:Предприятия (для организации клиентской части) можно использовать имеющиеся в платформе средства работы с HTTP: объекты HTTPСоединение, HTTPЗапрос и HTTPОтвет.
и солнце б утром не вставало, когда бы не было меня
Re: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, dimgel, Вы писали: D>4. Вывод: вот и границы применимости этого вашего REST-а нарисовались: помойки данных, где любые операции, отличные от чтения/записи даных, идут как неявные побочные эффекты.
Границы видны из аббревиатуры.
Если мы имеем дело с чем-то отличным от просмотра и/или изменения состояния, то REST нам и не нужен.
Re[7]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, Serginio1, Вы писали: S> Непроблема.В SOAP есть WS-ReliableMessaging, только в 1С нет поддержки этого протокола
Ага. Это называется "сначала мы создадим себе проблему, а потом будем прикручивать к ней неприлично дорогое решение". S> Зато у RESTа куча недостатков перед SOAP.
Ага, вот только назвать их все почему-то затрудняются. S> Кстати ту в 1С http://v8.1c.ru/o7/201312rest/index.htm смотрят в сторону ODATA
Ну так это и есть REST.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, Sharov, Вы писали:
S>Ребят, обожите. Если я правильно понял ваши идеи, то сейчас этих тестировщиков REST API S>навалом. Есть плагины для фф и для хрома. Fiddler опять же... S>В чем прикол?
Во-первых, в том, что я про сам факт существования этих тестировщиков раньше не слышал.
А во-вторых, в порекомендованной A13X-ом книге (в начале, до подробностей в главе про тело ответа не добрался ещё) что-то говорилось про передачу ссылок на связанные документы в составе ответа. Т.е. с помощью ссылок (игнорируемых программным клиентом) и XSLT можно очень удобную фигню замутить, с полноценной навигацией.
Re[8]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали: S>> Непроблема.В SOAP есть WS-ReliableMessaging, только в 1С нет поддержки этого протокола S>Ага. Это называется "сначала мы создадим себе проблему, а потом будем прикручивать к ней неприлично дорогое решение". S>> Зато у RESTа куча недостатков перед SOAP.
Прикручивать приходится потому, что 1С не поддерживает все возможности. Да понятие неприлично дорогое для меня непонятно, это пшик (2-3 строчки)по сравнению с реально написанным кодом)
Почему Метаданные и создание модели по WSDL. В RESTE пока я так понял в зачаточном положении. S>Ага, вот только назвать их все почему-то затрудняются. S>> Кстати ту в 1С http://v8.1c.ru/o7/201312rest/index.htm смотрят в сторону ODATA S>Ну так это и есть REST.
Но вот в большинстве то используют SOAP потому, что его легко использовать.
и солнце б утром не вставало, когда бы не было меня
Re[7]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, avpavlov, Вы писали:
N>>>Вы отвечаете, даже не попытавшись понять суть проблемы. Пусть передача тела по PUT завершилась, а перед получением OK от сервера порвалась связь. Как клиент поймёт, передавать заново или нет? A>>Почему она только для РЕСТ "нерешаема"?
N>Она решаема. С разной степенью надёжности в зависимости от применённых средств. Но Ваш метод точно её не решит.
Она решаема в REST со стопроцентной надёжностью. Клиент прекрасно понимает, передавать заново или нет: если он получил таймаут, или 5xx, то нужно повторять. Если 3xx, то нужно повторять с другим target URL, который можно получить из тела или заголовков ответа. Если 4xx, то нужно вернуть статус "не проконало" на уровень выше, т.к. данных для самостоятельного принятия решения недостаточно. И только если мы получаем 2xx, мы понимаем, что всё получилось успешно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
