Re[22]: Так ли хороша математическая нотация?
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 12.08.11 19:49
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Попытка номер 1 — POST-метод. Не работает — если теряем соединение после окончания метода, то у нас потеря документа.

C>Попытка номер 2 — POST-метод с уникальным GUID'ом для tracking'а, передаваемым в запросе. Не работает из-за вопросов безопасности.
C>Попытка номер 3 — разбиваем на два этапа: получение уникального GUID'а первым запросом, а потом использование этого GUID'а во втором.
Надо было начинать с идемпотентного PUT, используя GUID, который вполне безопасен.

C>А ещё из практических встреч — проблемы с кодировками запросов.

Непонятно, откуда они берутся. Вопрос кодировок в вебе стандпртизован вдоль и поперек — уж всяко лучше, чем в наколенных протоколах.
C>Ну и что дальше делать? Получается, что надо темпоральную базу иметь чуть ли не для всех доменных объектов при богатом REST-API. Или кидать в таком случае исключения, что не есть хорошо — блокировок нет, а сценарии с оптимистической блокировкой без атомарности получаются жуткими.
не понимаю вашу проблему. Темпоральная база нафиг не нужна. Достаточно хранить актуальную версию. Дальше стандартный подход — reload and repeat.
остальное допишу попожже.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[23]: Так ли хороша математическая нотация?
От: Cyberax Марс  
Дата: 12.08.11 20:00
Оценка:
Здравствуйте, Sinclair, Вы писали:

C>>Попытка номер 1 — POST-метод. Не работает — если теряем соединение после окончания метода, то у нас потеря документа.

C>>Попытка номер 2 — POST-метод с уникальным GUID'ом для tracking'а, передаваемым в запросе. Не работает из-за вопросов безопасности.
C>>Попытка номер 3 — разбиваем на два этапа: получение уникального GUID'а первым запросом, а потом использование этого GUID'а во втором.
S>Надо было начинать с идемпотентного PUT, используя GUID, который вполне безопасен.
Небезопасен. Так как источник генерирования GUID'ов может быть небезопасен.

C>>А ещё из практических встреч — проблемы с кодировками запросов.

S>Непонятно, откуда они берутся. Вопрос кодировок в вебе стандпртизован вдоль и поперек — уж всяко лучше, чем в наколенных протоколах.
Ага. Именно поэтому в мой сервис иногда данные приходят в cp1251.

S>не понимаю вашу проблему. Темпоральная база нафиг не нужна. Достаточно хранить актуальную версию. Дальше стандартный подход — reload and repeat.

S>остальное допишу попожже.
Мне нужно обновить два ресурса. Я делаю update на первый ресурс, а потом update на второй. Но при втором update'е получаю "чувак, ресурс устарел".

Що робыти? Откатить первое изменение, в общем случае нельзя. В SOAP для такой цели, хотя бы, есть WS-Transaction (при всех её недостатках).
Sapienti sat!
Re[12]: Так ли хороша математическая нотация?
От: Курилка Россия http://kirya.narod.ru/
Дата: 12.08.11 20:10
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:

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


M>>Это образно


AVK>В лес такие образы. В каком то форуме было правило, как только в топике упоминается Гитлер, топик сразу можно закрывать. В программистских флеймах полный аналог Гитлера — программирование АЭС.


Скорее всего речь о законе Годвина
Re[24]: Так ли хороша математическая нотация?
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 12.08.11 20:19
Оценка: +1
Здравствуйте, Cyberax, Вы писали:
S>>Надо было начинать с идемпотентного PUT, используя GUID, который вполне безопасен.
C>Небезопасен. Так как источник генерирования GUID'ов может быть небезопасен.
Это очень большая экзотика. В природе traceable GUIDs не встречаются уже очень много лет.
Чтобы выдавать это за недостаток протокола, надо быть более чем слегка параноидальным.

C>Ага. Именно поэтому в мой сервис иногда данные приходят в cp1251.

Неважно, в чём они приходят. Главное, чтобы headers соответстовали.

C>Мне нужно обновить два ресурса. Я делаю update на первый ресурс, а потом update на второй. Но при втором update'е получаю "чувак, ресурс устарел".

Это значит, что границы атомарности объектов были выбраны неправильно. Граница транзакции в REST совпадает с границей объекта. Больше сказать ничего нельзя без конкретных деталей.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[25]: Так ли хороша математическая нотация?
От: Cyberax Марс  
Дата: 12.08.11 20:27
Оценка:
Здравствуйте, Sinclair, Вы писали:

C>>Небезопасен. Так как источник генерирования GUID'ов может быть небезопасен.

S>Это очень большая экзотика. В природе traceable GUIDs не встречаются уже очень много лет.
S>Чтобы выдавать это за недостаток протокола, надо быть более чем слегка параноидальным.
Хех. Мне приходили GUID'ы вида 000000000000001, 000000000000002 и т.д.

C>>Ага. Именно поэтому в мой сервис иногда данные приходят в cp1251.

S>Неважно, в чём они приходят. Главное, чтобы headers соответстовали.
Ага, только вот не всегда.

C>>Мне нужно обновить два ресурса. Я делаю update на первый ресурс, а потом update на второй. Но при втором update'е получаю "чувак, ресурс устарел".

S>Это значит, что границы атомарности объектов были выбраны неправильно. Граница транзакции в REST совпадает с границей объекта. Больше сказать ничего нельзя без конкретных деталей.
Так мне нужно два объекта обновить "одновременно". REST это делает крайне тяжёлым.
Sapienti sat!
Re[22]: Так ли хороша математическая нотация?
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 12.08.11 20:30
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>Добавлю ещё:

C>6) Отсутствие само-описания типа WSDL для SOAP.
как раз с discoverability в REST всё очень хорошо. Но она рассчитана на человека, а не на автомат. Что, в общем-то, нормально: REST — это подход, а не какой-то конкретный стандарт.

C>7) Нет формальной спецификации — каждый понимает REST по-своему. Из-за этого, клиент практически для любого сервиса приходится писать после долгого вкуривания документации и экспериментов.

C>Для SOAP уже всё почти plug&play — я могу взять WSDL, по ней сгенерировать стабы и использовать в почти любом языке.
Если честно, то я не вижу связи. Без документации SOAP-сервис практически полностью бесполезен. Возможность сделать вызов "в любом языке" совершенно бесполезна без понимания, какие именно вызовы делать. Стандартной штукой является наличие "волшебных параметров", которые ссылаются на какие-то другие объекты, без малейшей идеи где идентификаторы этих объектов нужно брать.
RESTful API можно изучать с помощью браузера. Даже если нет вообще никакой документации, то более-менее понятно, какие именно вещи нужно делать.


C>8) Проблема с передачей сложных данных (даже банальный hash map нормально не передаётся) и т.д. Я понимаю, что сразу в таких случаях кричат: "JSON в POST/PUT", но в чём тогда отличие от SOAP?

Нет вообще никакой проблемы с передачей сложных данных. Отличие от SOAP — очень простое: через границу SOAP невозможно передать ссылку на объект. В REST все объекты являются адресуемыми, так что можно передавать URI.
Выбор представления для "сложных данных" — полностью на вас. Можно делать XHTML, XML, JSON или вообще произвольный application/octet-stream. Опять же, REST — это не стандарт. Это подход. На основе REST можно построить стандарт; и постепенно это происходит. Точно так же, как SOAP является результатом стандартизации архитектуры SOA.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[23]: Так ли хороша математическая нотация?
От: Cyberax Марс  
Дата: 12.08.11 20:49
Оценка:
Здравствуйте, Sinclair, Вы писали:

C>>Добавлю ещё:

C>>6) Отсутствие само-описания типа WSDL для SOAP.
S>как раз с discoverability в REST всё очень хорошо.
Агащаз. Как мне найти все параметры, по которым можно искать объект? Или список необходимых параметров при его создании?

А никак, только читать доку. Кстати, если происходит ошибка (скажем, из-за неправильного параметра) — то "you're out of luck". Стандарта на передачу ошибок тоже нет.

C>>7) Нет формальной спецификации — каждый понимает REST по-своему. Из-за этого, клиент практически для любого сервиса приходится писать после долгого вкуривания документации и экспериментов.

C>>Для SOAP уже всё почти plug&play — я могу взять WSDL, по ней сгенерировать стабы и использовать в почти любом языке.
S>Если честно, то я не вижу связи. Без документации SOAP-сервис практически полностью бесполезен.
Да ну? Я по WSDL практически всегда могу читать без проблем как работает сервис.

К примеру, наш родной service2.wsdl — что в нём непонятного?

S>Возможность сделать вызов "в любом языке" совершенно бесполезна без понимания, какие именно вызовы делать. Стандартной штукой является наличие "волшебных параметров", которые ссылаются на какие-то другие объекты, без малейшей идеи где идентификаторы этих объектов нужно брать.

Минимальный объём документации необходим, но не сильно большой.

S>RESTful API можно изучать с помощью браузера. Даже если нет вообще никакой документации, то более-менее понятно, какие именно вещи нужно делать.

КАК его изучать?

Вот тебе реальная ссылка на пример REST API:
http://chart.apis.google.com/chart?chs=220x150&cht=lc&chco=224499&chm=B,76A4FB,0,0,0&chxt=x,y&chxs=0,000000,12,0&chd=s:rswx7796&chxl=0:|Nov|Dec|Jan|Feb|Mar|Apr|May|Jun|1:||$4,999,700||$9,999,400||$14,999,100

Где тут discoverability? http://chart.apis.google.com/chart выдаёт 400. http://code.google.com/apis/chart/ перегоняет на http://code.google.com/apis/chart/ — где ты фиг найдёшь доку, так как этот API у них deprecated.

C>>8) Проблема с передачей сложных данных (даже банальный hash map нормально не передаётся) и т.д. Я понимаю, что сразу в таких случаях кричат: "JSON в POST/PUT", но в чём тогда отличие от SOAP?

S>Нет вообще никакой проблемы с передачей сложных данных. Отличие от SOAP — очень простое: через границу SOAP невозможно передать ссылку на объект.
Можно. Ровно как и в REST.

S>В REST все объекты являются адресуемыми, так что можно передавать URI.

Неверно. Скажем, я не могу из клиента передать ссылку серверу на мой объект — в мобильном телефоне веб-серверы не работают.

Не говоря уж о том, что это исключительно хрупкий подход.

S>Выбор представления для "сложных данных" — полностью на вас. Можно делать XHTML, XML, JSON или вообще произвольный application/octet-stream. Опять же, REST — это не стандарт. Это подход. На основе REST можно построить стандарт; и постепенно это происходит. Точно так же, как SOAP является результатом стандартизации архитектуры SOA.

Слова "REST — это подход" вообще гнилая отмаза. Примерно как "я стратег, а не тактик" в анекдоте про зайцев и сову.
Sapienti sat!
Re[22]: Так ли хороша математическая нотация?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.08.11 23:38
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>6) Отсутствие само-описания типа WSDL для SOAP.


http://www.ibm.com/developerworks/webservices/library/ws-restwsdl/

C>7) Нет формальной спецификации — каждый понимает REST по-своему.


Спецификации на что? Спецификация на REST это спецификация на HTTP. Другое дело, что поверх SOAP навернули кучу других спецификаций, аналогов коих для REST мало.
... << RSDN@Home 1.2.0 alpha 5 rev. 1530 on Windows 7 6.1.7601.65536>>
AVK Blog
Re[22]: Так ли хороша математическая нотация?
От: Константин Б. Россия  
Дата: 13.08.11 02:32
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


C>>>2) Нет возможности нормально делать диалоги — их приходится всё время эмулировать. Криво. Это самое бесящее.

S>>Не очень понятно, что такое "диалоги". Вас интересует stateful сессия? Да, её приходится эмулировать.
S>>Это оборотная сторона REST. Зато эти сессии появляются только там, где необходимо, а не там, где случайно получилось.
C>Вот ситуация — надо создать документ. В одном экземпляре.

C>Попытка номер 1 — POST-метод. Не работает — если теряем соединение после окончания метода, то у нас потеря документа.

C>Попытка номер 2 — POST-метод с уникальным GUID'ом для tracking'а, передаваемым в запросе. Не работает из-за вопросов безопасности.
C>Попытка номер 3 — разбиваем на два этапа: получение уникального GUID'а первым запросом, а потом использование этого GUID'а во втором.

C>Получается криво.


А как эта проблема решается прямо в SOAP?
Re[26]: Так ли хороша математическая нотация?
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 13.08.11 13:06
Оценка: 19 (1)
Здравствуйте, Cyberax, Вы писали:
C>Хех. Мне приходили GUID'ы вида 000000000000001, 000000000000002 и т.д.
Не вижу проблемы. Видимо, это оттого, что я не представляю себе вашу задачу. Если бы вы её мне описали, то я бы смог спроектировать для вас RESTful API.
А так мне остаётся только гадать, какую именно проблему с безопасностью вы подразумеваете.

C>Ага, только вот не всегда.

Это проблемы не вас, а клиента.

C>Так мне нужно два объекта обновить "одновременно". REST это делает крайне тяжёлым.

Ещё раз: в REST так не бывает. Классический пример, на котором иллюстрируют транзакции первокурсникам — "перевод денег со счёта". В REST он не делается путём декремента одного счёта и инкремента другого. В REST он делается при помощи записи объекта-транзакции, которая ссылается на оба счёта. Так понятно?
То есть делаем PUT на .../<userAccountID/transactions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.xml
Использование GUID гарантирует нам, что мы можем безопасно делать retry, не рискуя перевести деньги дважды. Использование userAccountID гарантирует нам, что транзакции от разных пользователей расположены в разных местах, что позволяет навернуть security и избежать проблемы нечаянного расшаривания кэша.

Ad-hoc транзакций в REST "из коробки" нет. Но их можно придумать, если есть убедительная причина.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[24]: Так ли хороша математическая нотация?
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 13.08.11 14:45
Оценка:
Здравствуйте, Cyberax, Вы писали:
C>Агащаз. Как мне найти все параметры, по которым можно искать объект? Или список необходимых параметров при его создании?
Вежливые люди при реализации протокола рендерят XHTML-формы с подсказками.
См. например http://apscatalog.com/all-app/
Видите — всё есть. И как искать, и как сабмиттить. Давайте посмотрим, сможете ли вы сходу найти вопрос, на который не получится ответить путём банального взгляда в браузер.

В более простых случаях REST полагается на WYSIWYG — то есть просто берёте документ, описывающий объект, и делаете PUT такого же документа.
Сам по себе документ может быть насколько угодно self-descriptive.
C>А никак, только читать доку. Кстати, если происходит ошибка (скажем, из-за неправильного параметра) — то "you're out of luck". Стандарта на передачу ошибок тоже нет.
Стандарт, конечно же, есть. И он ничуть не хуже, чем SOAP, в котором любимая ошибка — The creator of this fault did not specify a Reason.
Есть коды 4xx и 5xx, плюс возможность отрендерить сколько угодно деталей про ошибку.
C>Да ну? Я по WSDL практически всегда могу читать без проблем как работает сервис.
C>К примеру, наш родной service2.wsdl — что в нём непонятного?
Ну так он же родной. Попробуйте взять какой-нибудь настоящий сервис. Вот, из последнего, с чем мы имели дело — Office365 API.
Там даже с докой-то не разберёшься.

C>Минимальный объём документации необходим, но не сильно большой.

Ну давайте дадим мне ссылку на минимально интересный WSDL, и посмотрим, далеко ли удастся продвинуться без документации.

C>КАК его изучать?


C>Вот тебе реальная ссылка на пример REST API:

C>http://chart.apis.google.com/chart?chs=220x150&amp;cht=lc&amp;chco=224499&amp;chm=B,76A4FB,0,0,0&amp;chxt=x,y&amp;chxs=0,000000,12,0&amp;chd=s:rswx7796&amp;chxl=0:|Nov|Dec|Jan|Feb|Mar|Apr|May|Jun|1:||$4,999,700||$9,999,400||$14,999,100
Простите, а почему вы думаете, что это — REST?
REST — это не просто отказ от WSDL и SOAP.
C>Где тут discoverability? http://chart.apis.google.com/chart выдаёт 400. http://code.google.com/apis/chart/ перегоняет на http://code.google.com/apis/chart/ — где ты фиг найдёшь доку, так как этот API у них deprecated.
Вы, похоже, путаете REST c чем-то другим. REST — вот: http://developers.facebook.com/docs/reference/api/, см., в частности, раздел Introspection.

S>>В REST все объекты являются адресуемыми, так что можно передавать URI.

C>Неверно. Скажем, я не могу из клиента передать ссылку серверу на мой объект — в мобильном телефоне веб-серверы не работают.
Верно. Вы просто не понимаете, о чём я говорю.
C>Не говоря уж о том, что это исключительно хрупкий подход.
Поясняю: В соседнем ответе я привёл пример с банковской транзакцией.
Ну так в отличие от WSDL, где я должен буду передавать в метод Transfer() какие-то непрозрачные идентификаторы счетов, в REST я буду постить что-то типа
<transaction>
  <amount>165.24</amount>
  <source>.../vasya/accounts/checking.xml</source>
  <target>.../vasya/accounts/savings.xml</target>
</transaction>

Либо, вместо алиасов checking/savings, я буду писать прямо полные номера счетов. Whatever. Ничто не мешает протоколу работать в обоих случаях.
При этом про существование этих URL я могу узнать из того же сервиса, просто побраузив вокруг.
Речи про указание объектов на стороне клиента в REST не идёт.

C>Слова "REST — это подход" вообще гнилая отмаза. Примерно как "я стратег, а не тактик" в анекдоте про зайцев и сову.

Похоже, вы просто не умеете готовить REST и не очень хорошо понимаете, что это такое. Давайте продолжим эту дискуссию — я уверен, это существенно улучшит ваше отношение к REST.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[13]: Паттерн Стратегия
От: vdimas Россия  
Дата: 13.08.11 22:22
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Нет. Паттерн Стратегия выглядит точно так же (вплоть до UML-диаграммы), как и паттерн Состояние. И тем не менее, это разные паттерны.


Это если рассматривать только статическую часть схемы.
Вообще какой-то глупый упор в этих паттернах GoF на статическую структуру решения. И как следствие — в обсуждениях тоже. Статическая структура — это самый низкий, подчиненный уровень. Более того, ввиду своей подчиненности требуемому функционалу, могут иметь несколько подходящих вариантов исполнения. И наоборот, одно и то же исполнение может решать несколько задач. Зависит от того, какую модель происходящего мы нарисуем себе в голове.
Re[13]: Так ли хороша математическая нотация?
От: vdimas Россия  
Дата: 13.08.11 22:24
Оценка: +2
Здравствуйте, samius, Вы писали:

S>ну а стратегия — это ФВП для бедных

S>apply(f,x) = f(x)

Да все это семейство паттернов, сидящих на делегировании, сюда же можно приписать.
Re[24]: Так ли хороша математическая нотация?
От: Mamut Швеция http://dmitriid.com
Дата: 15.08.11 08:52
Оценка:
C>>>Добавлю ещё:
C>>>6) Отсутствие само-описания типа WSDL для SOAP.
S>>как раз с discoverability в REST всё очень хорошо.
C>Агащаз. Как мне найти все параметры, по которым можно искать объект? Или список необходимых параметров при его создании?

C>А никак, только читать доку. Кстати, если происходит ошибка (скажем, из-за неправильного параметра) — то "you're out of luck". Стандарта на передачу ошибок тоже нет.


Вообще-то есть, но мало кто реализует этот стандарт полностью: http://webmachine.basho.com/diagram.html


dmitriid.comGitHubLinkedIn
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.