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

ВВ>Значит, пора избавляться от неверных представлений. REST != передача запросов только через GET. Мне вообще-то казалось, что это очевидно.
Ты опять говоришь не о том. Дело не в передаче запросов, а в их семантике.
В REST краеугольный камень — отделение адресов объектов от методов манипуляции. Именно это и есть то, то означает аббревиатура. Именно это отличает REST от внешне похожих вещей. Да, красивость адресов — эффект вторичный. Но существенным является именно то, что для любого объекта применим глагол GET — не в смысле HTTP 1.1, а в смысле retrieve. И этот глагол обязан не иметь побочных эффектов. Если у тебя в протоколе такой глагол есть — ок, ты можешь начинать строить рест. Если нету — всё, скажи ресту досвидания.
Если у тебя для чтения данных применяется метод, который не имеет safe семантики — всё, это не рест.

Дальше тебе придется продумать, как осуществлять манипуляции с объектами. И опять тебе понадобятся специальные глаголы с заведомо известными свойствами, типа PUT и DELETE.

ВВ>Конвенция — да, ради бога. Только вот никаких общепринятых норм, W3C стандартов тут нет.
Что значит "ради бога"? Я тебе пытаюсь растолковать, что тебе эту конвенцию придется как-то изобрести и задокументировать. А потом придется ей следовать, а для этого писать какой-то объем кода.

ВВ>Это в HTTP есть "предопределенные глаголы", а не в РЕСТ. Не путай.
Я как раз не путаю. Глаголы есть именно в РЕСТ. Просто HTTP предоставляет их в готовом виде из коробки.

ВВ>У меня нет никаких ендпоинтов вообще. Есть уникальный адрес. Или лучше — fully qualified name — отлично масштабируемая штука, совершенно независимая от "глаголов", протоколов и прочей муры.
Что такое "fully qualified name"? Что с ней можно сделать и как?

ВВ>Очень просто:
ВВ>

ВВ>id=2345&name=Name&status=1...
ВВ>

ВВ>переданное в кодировке www-url-encoding через HTTP POST.
Отлично. Во-первых, хочется понять, откуда об этом узнает клиент. Запрос на запись у тебя вообще никак не связан с запросом на чтение. Гайдлайн номер 4 только что был нарушен.

Ок, хрен с ним. Я получаю в ответ на этот запрос таймаут. Что мне делать? Можно ли повторять этот же запрос, или он создаст лишний экземпляр объекта? Где взять информацию о том, что делать?

ВВ>Или:
ВВ>Переданное через POST.

ВВ>И причему тут УРЛ мне абсолютно непонятно. Но ты видимо хочешь записывать тоже через GET, да?
Нет, я хочу записывать
1. Такую же структуру, как я и прочитал. Потому что Representational State Transfer. То есть нельзя рассчитывать на то, что клиент самопроизвольно догадается, как превратить JSON в URLEncoding.
2. через глагол с идемпотентной семантикой. То есть если у меня неизвестен статус запроса, то я хочу иметь гарантию безопасного повтора до тех пор, пока не получу детерминированный ответ.
Этим требованиям удовлетворяет глагол PUT.


ВВ>А к чему ты это? Речь была, напомню, о том, заставляют ли тебя злобные SOAP Web Services пихать в кучу, в один веб-сервис, работу с разными объектами.
Ну конечно же заставляют. Я по прежнему прошу показать мне хоть один соаповый сервис в котором, к примеру, для работы с разными сообщениями используются разные ендпоинты. Нет, волшебным образом окажется, что сервис предоставляет ровно один адрес для всех-всех объектов, которые видны через него, как через замочную скважину.

ВВ>Кстати, SOAP WS — это не RPC вообще-то.
А что же это?

ВВ>Меня, кстати, устраивает HTTP протокол полностью. Меня не устраивает ограничивать возможности по конструированию запросов только методом GET, которую ты к тому же взял с потолка.
Бред какой-то. Я не предлагал ограничиваться методом GET. Им нужно ограничиваться только для запросов на чтение. Потому что из всех глаголов HTTP только он гарантирует нужную семантику.

ВВ>>> Можно вот на REST написать сервис, умеющий искать мелодию по ее фрагменту? И как будет выглядеть адрес?
S>>Можно. Но при реализации поверх HTTP придется немножко повстревать, чтобы обойти ограничения дефолтных реализаций. А если не заморачиваться ограничениями клиентов, то можно и напрямую — вписать base64 от фрагмента мелодии в URL резалтсета.

ВВ>А если не влезет?
ВВ>Вообще это смешно уже блин — все что угодно, только бы в УРЛ запихать. Попробуй мыслить шире. Адрес объекта — это не обязательно УРЛ, это любая удобная тебе абстракция.
Я мыслю достаточно широко. Адрес объекта должен быть отделён от метода получения объекта по этому адресу.

ВВ>А я говорю о том, что WCF это инструмент. С помощью него можно реализовать полностью соответствующий W3C веб-сервис,
Что такое "соответствующий W3C"? w3c — это консорциум. Он наплодил великое множество совершенно разных стандартов, далеко не все из которых являются хоть сколь-нибудь удачными. Чему именно будет соответствовать сервис на WCF?

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

S>Можно ли нарулить REST-style API на WCF?
Введение в службы RESTful с использованием WCF

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

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

S>>Они — не предоставляют. REST — предоставляет, доставляет, и пост-доставляет.
S>>Идея примерно такая: в REST все действия сводятся к передаче состояния. Значит, для обеспечения атомарности некоторой транзакции, нужно свести всю транзакцию к одному состоянию.
S>>Ну вот например: делаем GET на список заказов; правим в каждом поле "статус" в "reserved" и делаем PUT.
S>>Если 200 Ok — значит всё прошло успешно. Если нет — получим уместную 4xx либо 5xx.

S>>При этом каждый отдельный заказ может как быть монолитным ресурсом, так и родительским списком под-ресурсов. Так что для подготовки заказа можно делать POST айтема на адрес .../orders/11234532/items/ и получать 201 Object Created. Ну, а если перед POST кто-то успел сделать PUT либо статуса ордера в reserved, либо списка ордеров, как я написал выше, то попытка добавить айтем получит 409 либо 400.
GZ>Мягко говоря — мне это не нравится. Это получается архитектура, которая вводит ограничения на постановку.
Никаких ограничений на постановку, просто постановка в терминах состояния, а не в терминах действия.

GZ>Да и писанины немало.
Это к самому rest мало отношения имеет. В основном слабость библиотек, которые изначально больше рассчитаны на SOAP подход.

GZ>А если клиент в процессе заполнения почуствовал себя плохо и уехал лечить псориаз?
Значит запросов вообще не будет, никаких откатов\компенсаций не потребуется. Это кстати сэкономи немало писанины в тяжелых сценариях.

GZ>Или такой сценарий:
GZ>В ответ на документ, пользователь пишет письмо, и прикладывает другой документ. При этом письмо — не является документом, и принадлежит иерархии профайла пользователя, а не документов. Как их сохранить эти две сущности согласованно?
Пусть документы у нас адресуются по /Document(id), а а писма по /Detter(id).
Никто не мешает выполнять указанный тобой сценарий с помощью POST на url /Document(someId)/responceLetter
В запостенном объекте должны быть все приложенные документы (или ссылки на них).

Если каждый ресурс (объект) доступен по некоторому URL, то это не означает что он должен быть доступен только по одному URL.

Привет всем!

С Silverlight знаком слабо.
Вот хотел бы услышать мнения о том сможет ли силверлайт заменить асп в будущем? Какова будет его основная область применения?
Чем он лучше флеша?

Спасибо!

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

P>Привет всем!

P>С Silverlight знаком слабо.
Наверное стоит познакомиться поближе. Рекомендую начать с вебкастов на techdays.ru

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

P>Привет всем!

P>С Silverlight знаком слабо.
P>Вот хотел бы услышать мнения о том сможет ли силверлайт заменить асп в будущем? Какова будет его основная область применения?

Поработить мир

P>Чем он лучше флеша?

В инсталляторе Silverlight будет деинсталлятор флеша, так что таких вопросов возникать не будет

P>Спасибо!

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

F>Да, конечно, Silverlight выполняется на стороне клиента.
F>Но что мешает перенести необходимые функции на сторону сервера?
F>Я про WCF-службы и обращение к ним из приложения Silverlight, если возникнет такая необходимость?
В таком случае мы говорим про замену ASP.NET на WCF, а сильверлайт тут где-то сбоку.
В принципе, я не против, осталось только понять, какие преимущества даёт WCF. Будет ли оно масштабироваться так же хорошо; есть ли там поддержка кэширования; есть ли там поддержка балансировки нагрузки, как там с деплойментом клиента и сервера, и прочие радости. Я не слишком глубого знаком с WCF. Но в целом в последнее время меня мало привлекают RPC-style технологии для глобально-распределенных приложений. Можно ли нарулить REST-style API на WCF? Так ли это просто, как на ASP.NET MVC Framework?
Пока что всё выглядит так, что лучшим бэк-ендом для Silverlight по-прежнему остаётся ASP.NET.

Здравствуйте, peer, Вы писали:
[поскипано]

Я немного поумничаю

Технология подбирается под задачу

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

P>Привет всем!

P>С Silverlight знаком слабо.
P>Вот хотел бы услышать мнения о том сможет ли силверлайт заменить асп в будущем? Какова будет его основная область применения?
P>Чем он лучше флеша?

P>Спасибо!

Сразу видны глубокие знания предмета обсуждения...
(Сорри, не удержался )

Здравствуйте, peer, Вы писали:
P>Вот хотел бы услышать мнения о том сможет ли силверлайт заменить асп в будущем?
Нет, не сможет. ASP — серверная технология, Silverlight — клиентская. Кстати, если будешь и дальше путать ASP и ASP.NET — затопчут.
P>Какова будет его основная область применения?
Rich Internet Applications
P>Чем он лучше флеша?
Тем, что он text-based, поэтому формировать сильверлайтную разметку на лету не в пример проще.

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

P>>Вот хотел бы услышать мнения о том сможет ли силверлайт заменить асп в будущем?
S>Нет, не сможет. ASP — серверная технология, Silverlight — клиентская.

Да, конечно, Silverlight выполняется на стороне клиента.
Но что мешает перенести необходимые функции на сторону сервера?
Я про WCF-службы и обращение к ним из приложения Silverlight, если возникнет такая необходимость?
А клиентский код писать на C# по-моему удобнее,
чем делать то же при помощи javascript.
Да, на сегодняшний день для asp.net гораздо больше сторонних библиотек. Но я думаю, что эта ситуация довольно быстро изменится,-
например в 3-й версии silverlight обещали 60 новых готовых контролов.
Поправьте меня, если я не прав.

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

F>например в 3-й версии silverlight обещали 60 новых готовых контролов.
F>Поправьте меня, если я не прав.

Да уже для второй версии есть Silverlight Controls Toolkit, который содержит достаточное количество полезных контролов... По крайней мере, я пока не сталкивался с ситуацией, в которой мне не хватало бы того, что есть "изкаропки" + этот тулкит.

Хотя нет, один раз всё же было — не хватало котрола, умеющего рисовать HTML, правда в гугле моментально они нашлись в ассортименте

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

S> Я не слишком глубого знаком с WCF. Но в целом в последнее время меня мало привлекают RPC-style технологии для глобально-распределенных приложений. Можно ли нарулить REST-style API на WCF? Так ли это просто, как на ASP.NET MVC Framework?

Мне вот интересно — что такого по-твоему должно быть в WCF, чтобы в REST-стиле или вообще нельзя было ничего сделать или типа очень сложно? И какое отношение к REST имеет MVC?

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

ВВ>Мне вот интересно — что такого по-твоему должно быть в WCF, чтобы в REST-стиле или вообще нельзя было ничего сделать или типа очень сложно?
Типа например должно быть отсутствие встроенного умения передавать в ответ на один вызов набор ендпоинтов для следующих вызовов. Типа должно быть отсутствие встроенных возможностей отличать идемпотентные вызовы от безопасных и небезопасных. Типа должно быть отсутствие встроенных возможностей управления кэшированием результатов. В принципе, этого достаточно для того, чтобы REST-стиль было получить достаточно сложно для переключения на альтернативные технологии.
ВВ>И какое отношение к REST имеет MVC?
Очень простое: MVC — движок, на котором удобно делать REST. В частности, он сильно облегчает процесс построения адресного пространства объектов (по сравнению со, скажем, веб-формами и голыми хэндлерами), а также облегчает процесс его использования (благодаря типизированным методам генерации ссылок).

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

ВВ>>Мне вот интересно — что такого по-твоему должно быть в WCF, чтобы в REST-стиле или вообще нельзя было ничего сделать или типа очень сложно?
S>Типа например должно быть отсутствие встроенного умения передавать в ответ на один вызов набор ендпоинтов для следующих вызовов. Типа должно быть отсутствие встроенных возможностей отличать идемпотентные вызовы от безопасных и небезопасных. Типа должно быть отсутствие встроенных возможностей управления кэшированием результатов. В принципе, этого достаточно для того, чтобы REST-стиль было получить достаточно сложно для переключения на альтернативные технологии.

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

ВВ>>И какое отношение к REST имеет MVC?
S>Очень простое: MVC — движок, на котором удобно делать REST. В частности, он сильно облегчает процесс построения адресного пространства объектов (по сравнению со, скажем, веб-формами и голыми хэндлерами), а также облегчает процесс его использования (благодаря типизированным методам генерации ссылок).

Что такое "адресное пространство объектов", как это связано с REST и причем тут MVC?

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

ВВ>И судя по всему типа должно быть отсутствие понимания, что такое REST чтобы все вышеозначенное стало вдруг "требованием".
А в чем проблема с пониманием REST? Вообще-то это вроде как Representational State Transfer, для которого принципиально важно уметь всё, что я перечислил.
Если у тебя есть какое-то более другое понимание того, что необходимо для REST, а что — лишнее, то велкам изложить его тут.

ВВ>Что такое "адресное пространство объектов", как это связано с REST и причем тут MVC?
Вообще-то весь REST построен на том, что у каждого объекта есть уникальный адрес, по которому всегда можно его получить при помощи предопределенной операции GET — с предопределенной семантикой. Типичным анти-рест паттерном являются SOAP Web Services, у которых все "объекты" предметной области расположены по одному и тому же адресу, а выбор нужного осуществляется путем передачи его ID в параметрах вызова.
Кроме формального требования присваивать объектам различные адреса, есть неформальное требование делать пространство этих адресов систематически предсказуемым.
Поэтому, к примеру, адрес типа http://rsdn.ru/everything.aspx?id=23421&tts=21 — это плохо, а адреc типа http://rsdn.ru/users/sinclair/messages/2009/01/all.aspx — это хорошо.
И вот это второе в классических веб-формах достаточно неудобно обеспечивать.
А в ASP.NET MVC Framework — удобно.

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

ВВ>>И судя по всему типа должно быть отсутствие понимания, что такое REST чтобы все вышеозначенное стало вдруг "требованием".
S>А в чем проблема с пониманием REST? Вообще-то это вроде как Representational State Transfer, для которого принципиально важно уметь всё, что я перечислил.
S>Если у тебя есть какое-то более другое понимание того, что необходимо для REST, а что — лишнее, то велкам изложить его тут.

А что такое REST по-твоему? Это технология такая? А может, протокол? Или паттерн какой? Где, на каком этапе возникает необходимость во "встроенном умении передавать в ответ на один вызов набор ендпоинтов для следующих вызовов"?

REST — это стиль архитектуры распределенных приложений, не более. Самое тупое, но в то же вполне верное объяснение того, что это за зверь, можно найти здесь: http://learn-rest.blogspot.com/
Но даже если взять что-нибудь более заумное, вроде диссертации Филдинга, у которого тоже какое-то очень "свое" понимание REST, то что мы увидим:

REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

А вот твою интерпретацию я слышу впервые

ВВ>>Что такое "адресное пространство объектов", как это связано с REST и причем тут MVC?
S>Вообще-то весь REST построен на том, что у каждого объекта есть уникальный адрес, по которому всегда можно его получить при помощи предопределенной операции GET — с предопределенной семантикой.

Это фраза вообще ни о чем. Весь интернет построен на том, что у каждого объекта есть уникальный адрес, по которому всегда можно его получить при помощи предопределенной операции GET — с предопределенной семантикой.

S>Типичным анти-рест паттерном являются SOAP Web Services, у которых все "объекты" предметной области расположены по одному и тому же адресу, а выбор нужного осуществляется путем передачи его ID в параметрах вызова.

У веб-сервисов ничего нигде не расположено. Это, блин, технология. Расположено бывает у отдельных товарищей. REST надо сравнивать не с веб-сервисами, а, скажем, с SOA. И вот по поводу SOA я бы так уверенно не утверждал, что "все объекты предметной области расположены по одному и тому же адресу".

S>Кроме формального требования присваивать объектам различные адреса, есть неформальное требование делать пространство этих адресов систематически предсказуемым.
S>Поэтому, к примеру, адрес типа http://rsdn.ru/everything.aspx?id=23421&tts=21 — это плохо, а адреc типа http://rsdn.ru/users/sinclair/messages/2009/01/all.aspx — это хорошо.
S>И вот это второе в классических веб-формах достаточно неудобно обеспечивать.
S>А в ASP.NET MVC Framework — удобно.

Это все очень правильно и верно, только вот никакого отношения к REST не имеет.

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

S>В таком случае мы говорим про замену ASP.NET на WCF, а сильверлайт тут где-то сбоку.
S>В принципе, я не против, осталось только понять, какие преимущества даёт WCF. Будет ли оно масштабироваться так же хорошо;
да, IIS может выступать контейнером
S>есть ли там поддержка кэширования;
да
S> есть ли там поддержка балансировки нагрузки, как там с деплойментом клиента и сервера, и прочие радости.
есть
S> Я не слишком глубого знаком с WCF. Но в целом в последнее время меня мало привлекают RPC-style технологии для глобально-распределенных приложений. Можно ли нарулить REST-style API на WCF?
есть даже спец binding= webHttpBinding

пока SL тупо далеко не у всех стоит, кроме того надо его учить, а asp.net есть уже годами.

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

ВВ>Это фраза вообще ни о чем. Весь интернет построен на том, что у каждого объекта есть уникальный адрес, по которому всегда можно его получить при помощи предопределенной операции GET — с предопределенной семантикой.
Далеко не весь. Например SOAP предполагает что все объекты отдаются в ответ на POST с определенным телом запроса.

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

ВВ>А что такое REST по-твоему? Это технология такая? А может, протокол? Или паттерн какой? Где, на каком этапе возникает необходимость во "встроенном умении передавать в ответ на один вызов набор ендпоинтов для следующих вызовов"?

ВВ>REST — это стиль архитектуры распределенных приложений, не более. Самое тупое, но в то же вполне верное объяснение того, что это за зверь, можно найти здесь: http://learn-rest.blogspot.com/
Прекрасно. Ты сам-то по этой ссылке ходил?
http://learn-rest.blogspot.com/2008/02/rest-design-guidelines.html
Цитирую:

Rather than letting clients construct URLs for additional actions, include the actual URLs with REST responses

Это и есть то, о чем я говорю — встроенное умение передавать дополнительные адреса в ответе.

ВВ>А вот твою интерпретацию я слышу впервые
Это ты просто выделываешься.
Просто пройди по списку гайдлайнов реста, и прикинь, насколько легко их выполнять при помощи WCF. При помощи ASP.NET

ВВ>>>Что такое "адресное пространство объектов", как это связано с REST и причем тут MVC?
S>>Вообще-то весь REST построен на том, что у каждого объекта есть уникальный адрес, по которому всегда можно его получить при помощи предопределенной операции GET — с предопределенной семантикой.

ВВ>Это фраза вообще ни о чем. Весь интернет построен на том, что у каждого объекта есть уникальный адрес, по которому всегда можно его получить при помощи предопределенной операции GET — с предопределенной семантикой.
Нет. Это заблуждение. Очень большая часть объектов в вебе расположена позади неуникальных адресов, по которым ничего полезного через предопределённую операцию GET получить нельзя.

S>>Типичным анти-рест паттерном являются SOAP Web Services, у которых все "объекты" предметной области расположены по одному и тому же адресу, а выбор нужного осуществляется путем передачи его ID в параметрах вызова.

ВВ>У веб-сервисов ничего нигде не расположено. Это, блин, технология. Расположено бывает у отдельных товарищей.
Бугога. Ну покажи мне "неотдельных товарищей", которые смогли на основе этой блин-технологии реализовать отдачу SOAP-респонсов через гет по уникальным адресам для каждого объекта. Технология накладывает ограничения на реализацию. На SOAP полноценный REST получить невозможно.

REST надо сравнивать не с веб-сервисами, а, скажем, с SOA. И вот по поводу SOA я бы так уверенно не утверждал, что "все объекты предметной области расположены по одному и тому же адресу".
SOA, насколько я понимаю, вообще ортогональна REST. Поэтому мне непонятно, что тут можно сравнивать. Ты, наверное, придаешь термину REST слишком абстрактный смысл.

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

ВВ>>REST — это стиль архитектуры распределенных приложений, не более. Самое тупое, но в то же вполне верное объяснение того, что это за зверь, можно найти здесь: http://learn-rest.blogspot.com/
S>Прекрасно. Ты сам-то по этой ссылке ходил?
S>http://learn-rest.blogspot.com/2008/02/rest-design-guidelines.html
S>Цитирую:
S>

S>Rather than letting clients construct URLs for additional actions, include the actual URLs with REST responses

S>Это и есть то, о чем я говорю — встроенное умение передавать дополнительные адреса в ответе.

И где ты здесь видишь необходимость выдачи нескольких ендпоинтов в ответ на запрос? Тут вообще никаких ендопоинтов нет. Есть абсолютно абстрактный адрес. Вместо

{
"ProductName": "Computer",
"ProductId": "2345"
}

передаем

{
"ProductName": "Computer",
"ProductId": "http://domain/products/2345"
}

Теперь внимание, вопрос. Как по-твоему должна быть организована технология, чтобы она накладывала ограничение на формирование идентификаторов объектов? Даже в самом жестком на формат передаваемых данных SOAP RPC с этим никаких проблем.

ВВ>>А вот твою интерпретацию я слышу впервые
S>Это ты просто выделываешься.
S>Просто пройди по списку гайдлайнов реста, и прикинь, насколько легко их выполнять при помощи WCF. При помощи ASP.NET

Мне кажется, это ты выделываешься. Сама постановка вопроса в стиле — а легко ли сделать REST с помощью WCF по сравнению с ASP.NET — вообще звучит довольно забавно. Это все равно что сравнивать теплое с мягким. Причем я так и не понял, что тебе дает MVC для REST-a. Удобный способ красивые УРЛы делать?
Все, что нужно для реализации REST — это HttpWebRequest.

ВВ>>У веб-сервисов ничего нигде не расположено. Это, блин, технология. Расположено бывает у отдельных товарищей.
S>Бугога. Ну покажи мне "неотдельных товарищей", которые смогли на основе этой блин-технологии реализовать отдачу SOAP-респонсов через гет по уникальным адресам для каждого объекта. Технология накладывает ограничения на реализацию. На SOAP полноценный REST получить невозможно.

Только вот мы говорили, о том, что в случае с веб-сервисами никто тебя не обязывает "сваливаливать" в кучу, "по одному адресу" все объекту. Более того, как только ты попытаешься хорошо спроектировать свои веб-сервисы, выделить каждый из них, разделить их по ролям — а тут уже остается один шаг до SOA — то все уже становится совсем не так однозначно.

S>REST надо сравнивать не с веб-сервисами, а, скажем, с SOA. И вот по поводу SOA я бы так уверенно не утверждал, что "все объекты предметной области расположены по одному и тому же адресу".
S>SOA, насколько я понимаю, вообще ортогональна REST. Поэтому мне непонятно, что тут можно сравнивать. Ты, наверное, придаешь термину REST слишком абстрактный смысл.

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

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

ВВ>И где ты здесь видишь необходимость выдачи нескольких ендпоинтов в ответ на запрос? Тут вообще никаких ендопоинтов нет. Есть абсолютно абстрактный адрес. Вместо

ВВ>{
ВВ> "ProductName": "Computer",
ВВ> "ProductId": "2345"
ВВ>}

ВВ>передаем

ВВ>{
ВВ> "ProductName": "Computer",
ВВ> "ProductId": "http://domain/products/2345"
ВВ>}
Как это нет? А что, по-твоему, "http://domain/products/2345", как не ендпоинт? Ведь я могу сделать по нему вызов и получить ответ. Покажи мне теперь аналог этого на SOAP-e. Где в рамках соапа описано, как мне отдать клиенту информацию типа "для редактирования этого продукта вызовите вот такой-то метод с такими-то параметрами".

ВВ>Теперь внимание, вопрос. Как по-твоему должна быть организована технология, чтобы она накладывала ограничение на формирование идентификаторов объектов? Даже в самом жестком на формат передаваемых данных SOAP RPC с этим никаких проблем.
Вот и покажи мне, каким образом в SOAP RPC будет работать аналог этой штуки.

ВВ>Мне кажется, это ты выделываешься. Сама постановка вопроса в стиле — а легко ли сделать REST с помощью WCF по сравнению с ASP.NET — вообще звучит довольно забавно. Это все равно что сравнивать теплое с мягким. Причем я так и не понял, что тебе дает MVC для REST-a. Удобный способ красивые УРЛы делать?
Как минимум да. А что тебя беспокоит? Ты думаешь, делать красивые урлы — это как-то очень просто? Моя практика показывает, что нифига. Как я уже десять раз здесь написал, на голых вебформах их реализовывать настолько неудобно, что 90% народу этим вообще не заморачивается. Во избежание, так сказать, последующего геморроя.

ВВ>Все, что нужно для реализации REST — это HttpWebRequest.
Вот этого я не понял. Для реализации REST, вообще-то, нужен IHttpHandler. Ты точно понимаешь, о чём говоришь? Покажи мне пример использования HttpWebRequest в REST-сервере.

ВВ>Только вот мы говорили, о том, что в случае с веб-сервисами никто тебя не обязывает "сваливаливать" в кучу, "по одному адресу" все объекту. Более того, как только ты попытаешься хорошо спроектировать свои веб-сервисы, выделить каждый из них, разделить их по ролям — а тут уже остается один шаг до SOA — то все уже становится совсем не так однозначно.
Что именно становится не так однозначно? Спецификация SOAP или идеология RPC?


ВВ>Ты знаешь, SOA возможно действительно ортогональна REST, хотя и не совсем. Но тут хотя бы есть основания для сравнения, мы не пытаемся сравнивать технологию или протокол со набором рекомендаций по созданию архитектуры.
REST нужно сравнивать не с SOA, а с RPC. Это архитектуры примерно одного уровня. Я, возможно, плохо понимаю что такое SOA, но моё понимание сводится к тому, что нет никаких причин для SOA-сервисов не общаться друг с другом по REST-протоколам.

А по поводу WCF я просто не в курсе. Если это очередная ботва для RPС, то ресту она будет только мешать.

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

S>Как это нет? А что, по-твоему, "http://domain/products/2345", как не ендпоинт? Ведь я могу сделать по нему вызов и получить ответ. Покажи мне теперь аналог этого на SOAP-e. Где в рамках соапа описано, как мне отдать клиенту информацию типа "для редактирования этого продукта вызовите вот такой-то метод с такими-то параметрами".

http://domain/products/2345 — это адрес, являющийся абстракцией конкретной реализации. А вот ендпоинт, особенно в связи с разговором про WCF, имеет вполне конкретное значение. Я, надеюсь, не изменю твои представления о мире, если скажу, что в REST необязательно формировать запросы с помощью GET?
Адрес, к примеру, может быть и такой:

{
"ProductName": "Computer",
"ProductId": "\\Products\Computers[@Id='2345']"
}

и это будет более чем нормальный адрес. И именно об этом и говорится в гайдлайнах, которые ты там нашел.

ВВ>>Теперь внимание, вопрос. Как по-твоему должна быть организована технология, чтобы она накладывала ограничение на формирование идентификаторов объектов? Даже в самом жестком на формат передаваемых данных SOAP RPC с этим никаких проблем.
S>Вот и покажи мне, каким образом в SOAP RPC будет работать аналог этой штуки.

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

S>Как минимум да. А что тебя беспокоит? Ты думаешь, делать красивые урлы — это как-то очень просто? Моя практика показывает, что нифига. Как я уже десять раз здесь написал, на голых вебформах их реализовывать настолько неудобно, что 90% народу этим вообще не заморачивается. Во избежание, так сказать, последующего геморроя.

Меня ничего не беспокоит. Я вот завтра приду и скажу — мужики, а мне кажется, что http://domain.com/products/2345 — это говно, давайте-ка вернемся к http://domain.com/?action=get_product&id=2345. И знаешь, что? Это будет по-прежнему REST.

ВВ>>Все, что нужно для реализации REST — это HttpWebRequest.
S>Вот этого я не понял. Для реализации REST, вообще-то, нужен IHttpHandler. Ты точно понимаешь, о чём говоришь? Покажи мне пример использования HttpWebRequest в REST-сервере.

Э, ну давай не утрировать. Для реализации REST достаточно голого HTTP и тех средств для работы с ним, которые дотнет предоставляет еще с самой первой версии. Именно об этом я и говорил. А все остальное, красивые УРЛы и проч. — не более чем просто шелуха, совершенно необязательная для создания системы в REST-стиле.

ВВ>>Только вот мы говорили, о том, что в случае с веб-сервисами никто тебя не обязывает "сваливаливать" в кучу, "по одному адресу" все объекту. Более того, как только ты попытаешься хорошо спроектировать свои веб-сервисы, выделить каждый из них, разделить их по ролям — а тут уже остается один шаг до SOA — то все уже становится совсем не так однозначно.
S>Что именно становится не так однозначно? Спецификация SOAP или идеология RPC?

Становится неоднозначно то, что ты до этого написал:

Типичным анти-рест паттерном являются SOAP Web Services, у которых все "объекты" предметной области расположены по одному и тому же адресу

Вот яркий пример — SOA, которая как ты сам говорил ортогональна REST, прекрасно реализуется на этих самых SOAP Web Services и никаких анти-паттернов там что-то не видно. А все потому, что SOAP Web Services — это не архитектура, а инструмент. Также и WCF — это инструмент, только куда более гибкий.

Вообще у меня складывается ощущение, что ты сводишь REST к некой уникальности физического адреса объекта. Зачем? К тому же это неверно. REST тебя не ограничивает в способах конструирования запроса, и адрес — это далеко не всегда адрес в адресной строке браузера. Можно вот на REST написать сервис, умеющий искать мелодию по ее фрагменту? И как будет выглядеть адрес?

S>А по поводу WCF я просто не в курсе. Если это очередная ботва для RPС, то ресту она будет только мешать.

И зря. Это совсем не ботва для RPС — такая уже есть, и на пенсию пока не собирается. На WCF можно спокойно реализовать W3C веб-сервис, с которым будет работать клиент на каком-нибудь линуксе. А про REST я вообще молчу. WCF — это не какой-то обновленный ремотинг, совсем.

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

ВВ>http://domain/products/2345 — это адрес, являющийся абстракцией конкретной реализации. А вот ендпоинт, особенно в связи с разговором про WCF, имеет вполне конкретное значение. Я, надеюсь, не изменю твои представления о мире, если скажу, что в REST необязательно формировать запросы с помощью GET?
Изменишь.
ВВ>Адрес, к примеру, может быть и такой:

ВВ>

ВВ>{
ВВ>"ProductName": "Computer",
ВВ>"ProductId": "\\Products\Computers[@Id='2345']"
ВВ>}
ВВ>

ВВ>и это будет более чем нормальный адрес. И именно об этом и говорится в гайдлайнах, которые ты там нашел.
Чтобы это было "нормальным" адресом, к нему должна быть некоторая конвенция о том, каким образом получить из этого адреса представление объекта. Где эта конвенция? Откуда REST-клиент будет узнавать о том, что делать с этим адресом?
В HTTP REST есть предопределенные глаголы, которые имеют предопределенную семантику.

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


ВВ>Меня ничего не беспокоит. Я вот завтра приду и скажу — мужики, а мне кажется, что http://domain.com/products/2345 — это говно, давайте-ка вернемся к http://domain.com/?action=get_product&id=2345. И знаешь, что? Это будет по-прежнему REST.
Это — да. А как будет выглядеть запись объекта?

ВВ>Э, ну давай не утрировать. Для реализации REST достаточно голого HTTP и тех средств для работы с ним, которые дотнет предоставляет еще с самой первой версии. Именно об этом я и говорил.
Не похоже. Ты говорил про какой-то HttpWebRequest, который к ресту вообще не имеет никакого отношения.


ВВ>>>Только вот мы говорили, о том, что в случае с веб-сервисами никто тебя не обязывает "сваливаливать" в кучу, "по одному адресу" все объекту. Более того, как только ты попытаешься хорошо спроектировать свои веб-сервисы, выделить каждый из них, разделить их по ролям — а тут уже остается один шаг до SOA — то все уже становится совсем не так однозначно.
S>>Что именно становится не так однозначно? Спецификация SOAP или идеология RPC?

ВВ>Становится неоднозначно то, что ты до этого написал:

ВВ>

ВВ>Типичным анти-рест паттерном являются SOAP Web Services, у которых все "объекты" предметной области расположены по одному и тому же адресу

ВВ>Вот яркий пример — SOA, которая как ты сам говорил ортогональна REST, прекрасно реализуется на этих самых SOAP Web Services и никаких анти-паттернов там что-то не видно.
А ты посмотри как следует. Можно реализовать SOA поверх SOAP, и это будет унылое сам знаешь что. А можно — поверх REST, и это будет весело и здорово. Антипаттерном является сам RPC-стиль.

ВВ>Вообще у меня складывается ощущение, что ты сводишь REST к некой уникальности физического адреса объекта.
Логического адреса объекта. Я не свожу REST к этому, не путай необходимое с достаточным.
ВВ>Зачем? К тому же это неверно. REST тебя не ограничивает в способах конструирования запроса, и адрес — это далеко не всегда адрес в адресной строке браузера.
Да, не ограничивает. Ок, у тебя есть какой-то другой, не-HTTP протокол, в котором есть предопределённые глаголы типа GET, POST, PUT, DELETE, про свойства которых заранее известно довольно много?
Прекрасно. Давай посмотрим, сколько кода потребуется написать для того, чтобы реализовать простейший сервис, реализующий REST на этом протоколе. И сравним с объемом кода, нужного для достижения аналогичной функциональности на том же ASP.NET MVC Framework.

ВВ> Можно вот на REST написать сервис, умеющий искать мелодию по ее фрагменту? И как будет выглядеть адрес?
Можно. Но при реализации поверх HTTP придется немножко повстревать, чтобы обойти ограничения дефолтных реализаций. А если не заморачиваться ограничениями клиентов, то можно и напрямую — вписать base64 от фрагмента мелодии в URL резалтсета.

ВВ>И зря. Это совсем не ботва для RPС — такая уже есть, и на пенсию пока не собирается. На WCF можно спокойно реализовать W3C веб-сервис, с которым будет работать клиент на каком-нибудь линуксе.
Линукс тут совершенно ни при чём. Я говорю не про платформенно-специфичный протокол RPC, а про RPC-стиль, которому соответствует ремотинг, RMI, RPC, XML-RPC, SOAP и еще много всякого унылого того. w3c веб-сервис — это что? SOAP? Ну так нельзя на соапе сделать REST. Кроме тривиальных частных случаев.

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

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

S>Пока что всё выглядит так, что лучшим бэк-ендом для Silverlight по-прежнему остаётся ASP.NET.

не уверен, WCF с силверлайт выглядит неплохо, так как обмен данными идет типизированый, а в случае с ASP.NET нужно как минимум JSon сериализатор

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

S>Ок, у тебя есть какой-то другой, не-HTTP протокол, в котором есть предопределённые глаголы типа GET, POST, PUT, DELETE, про свойства которых заранее известно довольно много?
S>Прекрасно. Давай посмотрим, сколько кода потребуется написать для того, чтобы реализовать простейший сервис, реализующий REST на этом протоколе. И сравним с объемом кода, нужного для достижения аналогичной функциональности на том же ASP.NET MVC Framework.

RPC: rest.get(...); rest.put(...); ... ? Только нах?

ВВ>> Можно вот на REST написать сервис, умеющий искать мелодию по ее фрагменту? И как будет выглядеть адрес?
S>Можно. Но при реализации поверх HTTP придется немножко повстревать, чтобы обойти ограничения дефолтных реализаций. А если не заморачиваться ограничениями клиентов, то можно и напрямую — вписать base64 от фрагмента мелодии в URL резалтсета.

Мне встать для апплодисментов? Кто-то меня недавно распекал за base64 в теле запроса, а сам готов его в URL засунуть. Гыг

ВВ>>И зря. Это совсем не ботва для RPС — такая уже есть, и на пенсию пока не собирается. На WCF можно спокойно реализовать W3C веб-сервис, с которым будет работать клиент на каком-нибудь линуксе.
S>Линукс тут совершенно ни при чём. Я говорю не про платформенно-специфичный протокол RPC, а про RPC-стиль, которому соответствует ремотинг, RMI, RPC, XML-RPC, SOAP и еще много всякого унылого того. w3c веб-сервис — это что? SOAP? Ну так нельзя на соапе сделать REST. Кроме тривиальных частных случаев.

С чего нельзя-то??? 200 OK статус меняется на boolean : True и далее по смыслу, в чем принципиальная нереализуемость??

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

ВВ>http://domain/products/2345 — это адрес, являющийся абстракцией конкретной реализации. А вот ендпоинт, особенно в связи с разговором про WCF, имеет вполне конкретное значение. Я, надеюсь, не изменю твои представления о мире, если скажу, что в REST необязательно формировать запросы с помощью GET?
S>Изменишь.

Значит, пора избавляться от неверных представлений. REST != передача запросов только через GET. Мне вообще-то казалось, что это очевидно.

ВВ>>и это будет более чем нормальный адрес. И именно об этом и говорится в гайдлайнах, которые ты там нашел.
S>Чтобы это было "нормальным" адресом, к нему должна быть некоторая конвенция о том, каким образом получить из этого адреса представление объекта. Где эта конвенция? Откуда REST-клиент будет узнавать о том, что делать с этим адресом?

Конвенция — да, ради бога. Только вот никаких общепринятых норм, W3C стандартов тут нет. Это тебе не веб-сервисы. И никаких "енд-поинтов тоже нет.

S>В HTTP REST есть предопределенные глаголы, которые имеют предопределенную семантику.

Это в HTTP есть "предопределенные глаголы", а не в РЕСТ. Не путай.

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

У меня нет никаких ендпоинтов вообще. Есть уникальный адрес. Или лучше — fully qualified name — отлично масштабируемая штука, совершенно независимая от "глаголов", протоколов и прочей муры.

ВВ>>Меня ничего не беспокоит. Я вот завтра приду и скажу — мужики, а мне кажется, что http://domain.com/products/2345 — это говно, давайте-ка вернемся к http://domain.com/?action=get_product&id=2345. И знаешь, что? Это будет по-прежнему REST.
S>Это — да. А как будет выглядеть запись объекта?

Очень просто:

id=2345&name=Name&status=1...

переданное в кодировке www-url-encoding через HTTP POST.
Или:

<Update Id="2345">
 <Property Name="name" Value="Name"/>
  ...
</Update>

Или:

{
 "Action": "Update",
 "ID" : 2345
  ...
}

Переданное через POST.
И причему тут УРЛ мне абсолютно непонятно. Но ты видимо хочешь записывать тоже через GET, да?

S>А ты посмотри как следует. Можно реализовать SOA поверх SOAP, и это будет унылое сам знаешь что. А можно — поверх REST, и это будет весело и здорово. Антипаттерном является сам RPC-стиль.

А к чему ты это? Речь была, напомню, о том, заставляют ли тебя злобные SOAP Web Services пихать в кучу, в один веб-сервис, работу с разными объектами. Правильный ответ — нет, не заставляют.
Кстати, SOAP WS — это не RPC вообще-то.

S>Да, не ограничивает. Ок, у тебя есть какой-то другой, не-HTTP протокол, в котором есть предопределённые глаголы типа GET, POST, PUT, DELETE, про свойства которых заранее известно довольно много?
S>Прекрасно. Давай посмотрим, сколько кода потребуется написать для того, чтобы реализовать простейший сервис, реализующий REST на этом протоколе. И сравним с объемом кода, нужного для достижения аналогичной функциональности на том же ASP.NET MVC Framework.

Опять двадцать пять. О чем ни начнешь говорить — заканчиваем MVC. Попробуй для разнообразия не приплетать его к каждой теме — получится куда интереснее, я тебя уверяю.
Меня, кстати, устраивает HTTP протокол полностью. Меня не устраивает ограничивать возможности по конструированию запросов только методом GET, которую ты к тому же взял с потолка.

ВВ>> Можно вот на REST написать сервис, умеющий искать мелодию по ее фрагменту? И как будет выглядеть адрес?
S>Можно. Но при реализации поверх HTTP придется немножко повстревать, чтобы обойти ограничения дефолтных реализаций. А если не заморачиваться ограничениями клиентов, то можно и напрямую — вписать base64 от фрагмента мелодии в URL резалтсета.

А если не влезет?
Вообще это смешно уже блин — все что угодно, только бы в УРЛ запихать. Попробуй мыслить шире. Адрес объекта — это не обязательно УРЛ, это любая удобная тебе абстракция.

S>Линукс тут совершенно ни при чём. Я говорю не про платформенно-специфичный протокол RPC, а про RPC-стиль, которому соответствует ремотинг, RMI, RPC, XML-RPC, SOAP и еще много всякого унылого того. w3c веб-сервис — это что? SOAP? Ну так нельзя на соапе сделать REST. Кроме тривиальных частных случаев.

А я говорю о том, что WCF это инструмент. С помощью него можно реализовать полностью соответствующий W3C веб-сервис, с которым клиент на любой платформе будет "общаться" как с самым обычным веб-сервисом. Но из-за WCF не становится новой версией web services enhancements. И точно также на нем можно сделать полноценный РЕСТ — без всякого "унылого" SOAP.

Здравствуйте, hattab, Вы писали:
H>RPC: rest.get(...); rest.put(...); ... ? Только нах?
Не, это несерьезно. Ребята, я вам серъезно говорю — воспроизвести при помощи RPC то, что рест-по-хттп умеет из коробки, вам денег не хватит. Как только я попрошу ввести поддержку компрессии, кэширования и так далее, вы встрянете по самые помидоры.
Потому что нету в RPC встроенного способа передавать out-of-band данные. А как только вы попробуете приклеить к RPC эти данные in-band, окажется, что вы огребли с обратной совместимостью вашего ендпоинта. И вам придется решать банальную проблему согласования версий протокола для клиента и сервера, которая в слаботипизированном ресте решается на раз-два.

H>Мне встать для апплодисментов? Кто-то меня недавно распекал за base64 в теле запроса, а сам готов его в URL засунуть. Гыг
Можешь хлопать сидя — уел, уел


H>С чего нельзя-то??? 200 OK статус меняется на boolean : True и далее по смыслу, в чем принципиальная нереализуемость??
А на что меняются статусы 100, 201, 206, 302, 303, 304, 307, 401, 403, 409, 503?
Дети, соап — ошибка природы.

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

H>>RPC: rest.get(...); rest.put(...); ... ? Только нах?
S>Не, это несерьезно. Ребята, я вам серъезно говорю — воспроизвести при помощи RPC то, что рест-по-хттп умеет из коробки, вам денег не хватит. Как только я попрошу ввести поддержку компрессии, кэширования и так далее, вы встрянете по самые помидоры.

XML-RPC. XML over HTTP. Сжатие — бай дизайн, кодировки — бай дизайн. Кеширования нема, да, но это уровень прикладного софта, оно ему виднее.

S>Потому что нету в RPC встроенного способа передавать out-of-band данные. А как только вы попробуете приклеить к RPC эти данные in-band, окажется, что вы огребли с обратной совместимостью вашего ендпоинта. И вам придется решать банальную проблему согласования версий протокола для клиента и сервера, которая в слаботипизированном ресте решается на раз-два.

Для XML-RPC out-of-band могут быть куки и прочие ляльки HTTP-транспорта.

H>>С чего нельзя-то??? 200 OK статус меняется на boolean : True и далее по смыслу, в чем принципиальная нереализуемость??
S>А на что меняются статусы 100, 201, 206, 302, 303, 304, 307, 401, 403, 409, 503?

В XML-RPC это будет faultCode в структуре fault, если перекладывать с HTTP транспорта, но можно на нем и оставить. Т.е. XML-RPC клиент получив 302/303 заспокойно перепостит по Location и не поперхнется.

S>Дети, соап — ошибка природы.

XML-RPC forever

Здравствуйте, hattab, Вы писали:
H>XML-RPC. XML over HTTP. Сжатие — бай дизайн, кодировки — бай дизайн. Кеширования нема, да, но это уровень прикладного софта, оно ему виднее.
Да-да, я в курсе. "Ему виднее" выливается тупо в отсутствие поддержки навсегда.

H>Для XML-RPC out-of-band могут быть куки и прочие ляльки HTTP-транспорта.
Куки имеют совершенно определённую семантику, которая непригодна для negotiation.

S>>А на что меняются статусы 100, 201, 206, 302, 303, 304, 307, 401, 403, 409, 503?

H>В XML-RPC это будет faultCode в структуре fault, если перекладывать с HTTP транспорта, но можно на нем и оставить. Т.е. XML-RPC клиент получив 302/303 заспокойно перепостит по Location и не поперхнется.
Ага, то есть два из 11 с грехом пополам поддержали. Молодцы, осталось смотреть на остальные 9 и завидовать.

H>XML-RPC forever
XML-RPC — еще большая ошибка. Он имеет все недостатки соапа, и никаких преимуществ.

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

S>Здравствуйте, hattab, Вы писали:
H>>XML-RPC. XML over HTTP. Сжатие — бай дизайн, кодировки — бай дизайн. Кеширования нема, да, но это уровень прикладного софта, оно ему виднее.
S>Да-да, я в курсе. "Ему виднее" выливается тупо в отсутствие поддержки навсегда.

Хорошее предположение... Тотальное кеширование выливается в несвоевременное обновление, траблы с секурностью...

H>>Для XML-RPC out-of-band могут быть куки и прочие ляльки HTTP-транспорта.
S>Куки имеют совершенно определённую семантику, которая непригодна для negotiation.

Весь negotiation на уровне транспорта, не? Транспорт XML-RPC -- HTTP, как и для REST.

S>>>А на что меняются статусы 100, 201, 206, 302, 303, 304, 307, 401, 403, 409, 503?

H>>В XML-RPC это будет faultCode в структуре fault, если перекладывать с HTTP транспорта, но можно на нем и оставить. Т.е. XML-RPC клиент получив 302/303 заспокойно перепостит по Location и не поперхнется.
S>Ага, то есть два из 11 с грехом пополам поддержали. Молодцы, осталось смотреть на остальные 9 и завидовать.

Ты не понял. XML-RPC клиент может преспокойно реагировать на статусные коды транспорта, в этом нет ни какой проблемы т.к. он же over... Просто помимо этого он имеет еще и свои, прикладные, возможности.

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

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

ОК. И как только у нас операция GET перестает ассоциироваться с соответствующим HTTP методом, то и возникают вопросы:
1) Каким образом должна быть реализована некая абстрактная технология, чтобы она не позволяла в ответ на запрос, в теле ответа, вернуть некий адрес (любой, формализованный в рамках нашей системы), по которому можно будет получить экземпляр объекта?
2) Причем тут ендпоинты?

ВВ>>Конвенция — да, ради бога. Только вот никаких общепринятых норм, W3C стандартов тут нет.
S>Что значит "ради бога"? Я тебе пытаюсь растолковать, что тебе эту конвенцию придется как-то изобрести и задокументировать. А потом придется ей следовать, а для этого писать какой-то объем кода.

И что? Да, придется изобрести. Достоинство РЕСТа в том числе и в том, что он тебе изначально никакую конвенцию не навязывает. Если язык HTTP в конкретном случае не устраивает, то не означает, что мы не можем использовать REST. Это лишь означает, что мы будем говорить на другом языке.

ВВ>>Это в HTTP есть "предопределенные глаголы", а не в РЕСТ. Не путай.
S>Я как раз не путаю. Глаголы есть именно в РЕСТ. Просто HTTP предоставляет их в готовом виде из коробки.

У тебя уже появляется некий загадочный REST HTTP, которого на самом деле нет. Да, REST хорошо ложится на HTTP — ну собственно и все. Опять-таки то самое "отделение адресов объектов от методов манипуляции", о котором ты говоришь, как-то не вызывает у меня автоматической ассоциаций с методами HTTP. REST как стиль организации распределенки именно что ратует за отделение мух от котлет и не более, а "предопределенные глаголы" — это HTTP.

ВВ>>У меня нет никаких ендпоинтов вообще. Есть уникальный адрес. Или лучше — fully qualified name — отлично масштабируемая штука, совершенно независимая от "глаголов", протоколов и прочей муры.
S>Что такое "fully qualified name"? Что с ней можно сделать и как?

А что можно сделать с HTTP URL?

ВВ>>переданное в кодировке www-url-encoding через HTTP POST.
S>Отлично. Во-первых, хочется понять, откуда об этом узнает клиент. Запрос на запись у тебя вообще никак не связан с запросом на чтение. Гайдлайн номер 4 только что был нарушен.

Правда?
Я привел три варианта передачи запросов на изменение — причем и XML тут не приступление — выбираешь какой хочешь. И да, в ответ на JSON посылать XML, наверное, не стоит. Ты, наверное, меня в этом хочешь обвинить?

S>Ок, хрен с ним. Я получаю в ответ на этот запрос таймаут. Что мне делать? Можно ли повторять этот же запрос, или он создаст лишний экземпляр объекта? Где взять информацию о том, что делать?

Тут хочется произнести вышеприведенное тобой слово — я в жизни его всегда с трудом выговариваю — идимпотенто... нет, идемпотентные. Причем, собственно, REST тут особо и не причем.
А, вспомнил! Ты же считаешь, что WCF в принципе не позволяет делать такую трудновыговариаемую штуку, вот в чем весь сыр-бор то.

ВВ>>И причему тут УРЛ мне абсолютно непонятно. Но ты видимо хочешь записывать тоже через GET, да?
S>Нет, я хочу записывать
S>1. Такую же структуру, как я и прочитал. Потому что Representational State Transfer. То есть нельзя рассчитывать на то, что клиент самопроизвольно догадается, как превратить JSON в URLEncoding.

Э, "клиенту" нужно прочитать спецификацию HTTP. Все содержимое что POST, что GET передается в этой кодировке.

S>2. через глагол с идемпотентной семантикой. То есть если у меня неизвестен статус запроса, то я хочу иметь гарантию безопасного повтора до тех пор, пока не получу детерминированный ответ.
S>Этим требованиям удовлетворяет глагол PUT.

А еще этим требованиям удовлетворяет глагол XXX-SUPER-VSTAV, который отсылает бинарные данные в deflate с нулевым оверхедом на терминал аэропорта о наиболее оптимальном маршруте для самолета, который мы не можем принять, а у него, блин, сейчас бензин закончится.

ВВ>>Кстати, SOAP WS — это не RPC вообще-то.
S>А что же это?

А у тебя любой SOAP ассоциируется с RPC? SOAP RPC — это отдельная шутка вообще-то. И это не веб-сервисы. У веб-сервисов другая штука — "конвертик", называется

ВВ>>А если не влезет?
ВВ>>Вообще это смешно уже блин — все что угодно, только бы в УРЛ запихать. Попробуй мыслить шире. Адрес объекта — это не обязательно УРЛ, это любая удобная тебе абстракция.
S>Я мыслю достаточно широко. Адрес объекта должен быть отделён от метода получения объекта по этому адресу.

Хорошо, и вывод какой? Я все еще жду примера каких-либо ограничений в технологии, которые не позволили бы этого добиться.

ВВ>>А я говорю о том, что WCF это инструмент. С помощью него можно реализовать полностью соответствующий W3C веб-сервис,
S>Что такое "соответствующий W3C"? w3c — это консорциум. Он наплодил великое множество совершенно разных стандартов, далеко не все из которых являются хоть сколь-нибудь удачными. Чему именно будет соответствовать сервис на WCF?

Он будет соответствовать стандартам SOAP, WSDL и пр., которые — уж не знаю, насколько ты их считаешь удачными — весьма широко применяются в индустрии. Или тебе ссылки привести?

Здравствуйте, GlebZ, Вы писали:
S>>Можно ли нарулить REST-style API на WCF?
GZ>Введение в службы RESTful с использованием WCF
Во, вот это — ответ не мальчика, но мужа. Не то, что жалкие попытки убедить меня, что эмуляция семантики HTTP внутри SOAP-сервиса — типа круче, чем нормальный стек в ASP.NET. В принципе выглядит неплохо, для чистых сервисов, наверное, даже компактнее, чем всякое там. Если бы еще кто-то взялся прикрутить обратный мэппинг URI для возвращаемых данных, типа как здесь — вообще было бы офигенно.

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

S>Во, вот это — ответ не мальчика, но мужа. Не то, что жалкие попытки убедить меня, что эмуляция семантики HTTP внутри SOAP-сервиса — типа круче, чем нормальный стек в ASP.NET. В принципе выглядит неплохо, для чистых сервисов, наверное, даже компактнее, чем всякое там. Если бы еще кто-то взялся прикрутить обратный мэппинг URI для возвращаемых данных, типа как здесь — вообще было бы офигенно.

Я бы ещё добавил, что описанное в статье решение идеально для hosted-сценариев, когда нужно встроить поддержку сервиса, к примеру, в свой Windows-сервис. Для ASP.NET MVC придётся либо поднимать IIS, либо хостить ASP.NET самостоятельно, по сравнению с парой строк кода по запуску WCF эта возможность выглядит неубедительно, и даже отсутствие обратного маппинга "искаропки" (хотя я не вижу особых проблем его реализации) ИМХО не является настолько важной фичей, чтобы ради неё так мучаться. Кроме того, в случае IIS мы имеем потенциальную необходимость организации IPC с основным сервисом, в случае же WCF мы находимся в одном процессе.

В общем, очередной trade-off. По мне так встраивать сервисы в существующие приложения проще на WCF (если нет планов по переписыванию на MVC), ну а в MVC-приложении выбор очевиден. Сейчас плотно взялся за MVC и пока в восторге от его возможностей — ModelBinder'ы и раутинг творят чудеса!

Здравствуйте, koandrew, Вы писали:
K>Я бы ещё добавил, что описанное в статье решение идеально для hosted-сценариев, когда нужно встроить поддержку сервиса, к примеру, в свой Windows-сервис. Для ASP.NET MVC придётся либо поднимать IIS, либо хостить ASP.NET самостоятельно, по сравнению с парой строк кода по запуску WCF эта возможность выглядит неубедительно, и даже отсутствие обратного маппинга "искаропки" (хотя я не вижу особых проблем его реализации) ИМХО не является настолько важной фичей, чтобы ради неё так мучаться. Кроме того, в случае IIS мы имеем потенциальную необходимость организации IPC с основным сервисом, в случае же WCF мы находимся в одном процессе.
Не очень понятно про сценарий нахождения чего-то в одном процессе, применительно к Silverlight. Если мы находимся в одном процессе, то надо просто включать WPF и ехать вообще безо всякой коммуникации.

А если мы разворачиваем Silverlight, то IIS скорее всего уже есть. Ну, разве что мы делаем консоль управления к нашему сервису, которая умеет работать через интернет. Тогда, правда, придется повоевать с обратной проблемой — IIS скорее всего уже стоит, и нам нельзя использовать 80й/443й порты. А на другие нас не пустят по умолчанию.

K>В общем, очередной trade-off. По мне так встраивать сервисы в существующие приложения проще на WCF (если нет планов по переписыванию на MVC), ну а в MVC-приложении выбор очевиден. Сейчас плотно взялся за MVC и пока в восторге от его возможностей — ModelBinder'ы и раутинг творят чудеса!
Не, про встраивания в "невеб" приложения я ничего и не говорил.

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

S>Во, вот это — ответ не мальчика, но мужа. Не то, что жалкие попытки убедить меня, что эмуляция семантики HTTP внутри SOAP-сервиса — типа круче, чем нормальный стек в ASP.NET. В принципе выглядит неплохо, для чистых сервисов, наверное, даже компактнее, чем всякое там. Если бы еще кто-то взялся прикрутить обратный мэппинг URI для возвращаемых данных, типа как здесь — вообще было бы офигенно.
Все это прекрасно. Но меня корежит следующее... Что будет со сложными транзакциями в которых участвуют несколько объектов? Транзакциям — идемподентность вредна. Да и размазывание транзакции между сервером и клиентом определенно доведет до цугундера(клиент отвалился, сервер курит). MVC не знаю. Еще не разбирался. Они что-нибудь предоставляют по этому поводу?

Здравствуйте, GlebZ, Вы писали:
GZ>Все это прекрасно. Но меня корежит следующее... Что будет со сложными транзакциями в которых участвуют несколько объектов? Транзакциям — идемподентность вредна. Да и размазывание транзакции между сервером и клиентом определенно доведет до цугундера(клиент отвалился, сервер курит). MVC не знаю. Еще не разбирался. Они что-нибудь предоставляют по этому поводу?
Они — не предоставляют. REST — предоставляет, доставляет, и пост-доставляет.
Идея примерно такая: в REST все действия сводятся к передаче состояния. Значит, для обеспечения атомарности некоторой транзакции, нужно свести всю транзакцию к одному состоянию.
Ну вот например: делаем GET на список заказов; правим в каждом поле "статус" в "reserved" и делаем PUT.
Если 200 Ok — значит всё прошло успешно. Если нет — получим уместную 4xx либо 5xx.

При этом каждый отдельный заказ может как быть монолитным ресурсом, так и родительским списком под-ресурсов. Так что для подготовки заказа можно делать POST айтема на адрес .../orders/11234532/items/ и получать 201 Object Created. Ну, а если перед POST кто-то успел сделать PUT либо статуса ордера в reserved, либо списка ордеров, как я написал выше, то попытка добавить айтем получит 409 либо 400.

Примеры рассмотрены в книжке RESTful Web Services.

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

S>Они — не предоставляют. REST — предоставляет, доставляет, и пост-доставляет.
S>Идея примерно такая: в REST все действия сводятся к передаче состояния. Значит, для обеспечения атомарности некоторой транзакции, нужно свести всю транзакцию к одному состоянию.
S>Ну вот например: делаем GET на список заказов; правим в каждом поле "статус" в "reserved" и делаем PUT.
S>Если 200 Ok — значит всё прошло успешно. Если нет — получим уместную 4xx либо 5xx.

S>При этом каждый отдельный заказ может как быть монолитным ресурсом, так и родительским списком под-ресурсов. Так что для подготовки заказа можно делать POST айтема на адрес .../orders/11234532/items/ и получать 201 Object Created. Ну, а если перед POST кто-то успел сделать PUT либо статуса ордера в reserved, либо списка ордеров, как я написал выше, то попытка добавить айтем получит 409 либо 400.
Мягко говоря — мне это не нравится. Это получается архитектура, которая вводит ограничения на постановку. Да и писанины немало. А если клиент в процессе заполнения почуствовал себя плохо и уехал лечить псориаз?
Или такой сценарий:
В ответ на документ, пользователь пишет письмо, и прикладывает другой документ. При этом письмо — не является документом, и принадлежит иерархии профайла пользователя, а не документов. Как их сохранить эти две сущности согласованно?

Здравствуйте, GlebZ, Вы писали:
GZ>Мягко говоря — мне это не нравится. Это получается архитектура, которая вводит ограничения на постановку. Да и писанины немало. А если клиент в процессе заполнения почуствовал себя плохо и уехал лечить псориаз?
Ничего плохого не случится. Что происходит, когда ты недописываешь письмо в гмэйле?

GZ>Или такой сценарий:
GZ>В ответ на документ, пользователь пишет письмо, и прикладывает другой документ. При этом письмо — не является документом, и принадлежит иерархии профайла пользователя, а не документов. Как их сохранить эти две сущности согласованно?
А что именно делается транзакцией? До тех пор, пока существут топологическая сортировка графа зависимостей, никаких проблем быть не должно: документ вполне можно закоммитить в сервер безо всякого письма. А потом уже отправлять письмо, если нужно.

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

GZ>>Мягко говоря — мне это не нравится. Это получается архитектура, которая вводит ограничения на постановку. Да и писанины немало. А если клиент в процессе заполнения почуствовал себя плохо и уехал лечить псориаз?
S>Ничего плохого не случится. Что происходит, когда ты недописываешь письмо в гмэйле?
Gmail — штука хорошая, но разработка стоит много денег. К тому же, там по определению задачи, каждый живет в своей песочнице, и копает собственной лопаткой.

GZ>>Как их сохранить эти две сущности согласованно?
S>А что именно делается транзакцией? До тех пор, пока существут топологическая сортировка графа зависимостей, никаких проблем быть не должно: документ вполне можно закоммитить в сервер безо всякого письма. А потом уже отправлять письмо, если нужно.
Наверно я неправильно выразился. Атомарно — необходимое условия сценария. Письмо и документы содержат ссылки друг на друга. Документ-ответ, как и письмо — должны сохраняться в одной транзакции ибо без ссылки, он не консинсентен. В бизнес-транзакцию запихивать — это минус stateless, плюс траблы с отслеживанием ее состояния.

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

GZ>>Или такой сценарий:
GZ>>В ответ на документ, пользователь пишет письмо, и прикладывает другой документ. При этом письмо — не является документом, и принадлежит иерархии профайла пользователя, а не документов. Как их сохранить эти две сущности согласованно?
G>Пусть документы у нас адресуются по /Document(id), а а писма по /Detter(id).
G>Никто не мешает выполнять указанный тобой сценарий с помощью POST на url /Document(someId)/responceLetter
G>В запостенном объекте должны быть все приложенные документы (или ссылки на них).
Эмулировать запуск сценария с помощью объекта? Прикольно.

Здравствуйте, GlebZ, Вы писали:
GZ>Эмулировать запуск сценария с помощью объекта? Прикольно.
Так это и есть вся идея REST. Там в принципе нет никаких других глаголов, кроме Получить, Изменить, Добавить, Удалить (где-то это уже встречалось...).

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

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

GZ>>>Или такой сценарий:
GZ>>>В ответ на документ, пользователь пишет письмо, и прикладывает другой документ. При этом письмо — не является документом, и принадлежит иерархии профайла пользователя, а не документов. Как их сохранить эти две сущности согласованно?
G>>Пусть документы у нас адресуются по /Document(id), а а писма по /Detter(id).
G>>Никто не мешает выполнять указанный тобой сценарий с помощью POST на url /Document(someId)/responceLetter
G>>В запостенном объекте должны быть все приложенные документы (или ссылки на них).
GZ>Эмулировать запуск сценария с помощью объекта? Прикольно.
Чего эмкулировать? Какого сценария?

Смотри:

Сохранить                   --------> POST
письмо                      --------> <тип объекта>
в ответ на документ         --------> /Document(someId)/responseLetter
с прикрепленным документом  --------> <поддерево обеъктов>

Способ реализации непосредственно из постановки задачи следует.

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

G>Чего эмкулировать? Какого сценария?

G>Смотри:
G>

G>Сохранить                   --------> POST
G>письмо                      --------> <тип объекта>
G>в ответ на документ         --------> /Document(someId)/responseLetter
G>с прикрепленным документом  --------> <поддерево обеъктов>
G>

G>Способ реализации непосредственно из постановки задачи следует.
Об этом и речь. В данном случае нам не нужен CRUD как таковой. Нам нужно действие выполняемое на сервере.

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

S>Так это и есть вся идея REST. Там в принципе нет никаких других глаголов, кроме Получить, Изменить, Добавить, Удалить (где-то это уже встречалось...).
Токмо тут нет требования идемподентности. Зато сериализованность — весьма важна. Это и бросилось в глаза.

Здравствуйте, GlebZ, Вы писали:
GZ>Токмо тут нет требования идемподентности.
Ага. Потому, что SQL всё же работает с реляциями, а не с отдельными строками.
GZ>Зато сериализованность — весьма важна. Это и бросилось в глаза.

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

GZ>Об этом и речь. В данном случае нам не нужен CRUD как таковой. Нам нужно действие выполняемое на сервере.
Это точка зрения. Представь себе язык программирования, где методов нету вообще, а есть только свойства. Уверяю тебя, ты быстро научишься писать на нём произвольные программы.

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

GZ>>Об этом и речь. В данном случае нам не нужен CRUD как таковой. Нам нужно действие выполняемое на сервере.
S>Это точка зрения. Представь себе язык программирования, где методов нету вообще, а есть только свойства. Уверяю тебя, ты быстро научишься писать на нём произвольные программы.
Если ты проектируешь(развиваешь) проект от данных — то может быть и полезно. Если от действий пользователя(как я) — то я не нахожу здесь плюсов. Покамест никакого плюса, кроме адресуемости данных, я не вижу. Ито, это плюс достаточно абстрактный, так как за эту фичу мне денег не заплатят. По сравнению с более развитым интерфейсом — REST, это самоограничение.

Здравствуйте, GlebZ, Вы писали:
GZ>Если ты проектируешь(развиваешь) проект от данных — то может быть и полезно. Если от действий пользователя(как я) — то я не нахожу здесь плюсов. Покамест никакого плюса, кроме адресуемости данных, я не вижу. Ито, это плюс достаточно абстрактный, так как за эту фичу мне денег не заплатят. По сравнению с более развитым интерфейсом — REST, это самоограничение.
Тут фишка вот в чём — проектировать от действий пользователя надо UI. А вот структура внутренней модели частенько оказывается лучше выразимой именно в терминах данных. Просто "действия" гораздо хуже масштабируются — для них крайне тяжело делать метавыводы, навроде "зависит ли результат от порядка выполнения двух таких-то действий".

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

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

G>>Чего эмкулировать? Какого сценария?

G>>Смотри:
G>>

G>>Сохранить                   --------> POST
G>>письмо                      --------> <тип объекта>
G>>в ответ на документ         --------> /Document(someId)/responseLetter
G>>с прикрепленным документом  --------> <поддерево обеъктов>
G>>

G>>Способ реализации непосредственно из постановки задачи следует.
GZ>Об этом и речь. В данном случае нам не нужен CRUD как таковой. Нам нужно действие выполняемое на сервере.
В не-REST случае оно как выглядеть будет?

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

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

GZ>>>Об этом и речь. В данном случае нам не нужен CRUD как таковой. Нам нужно действие выполняемое на сервере.
S>>Это точка зрения. Представь себе язык программирования, где методов нету вообще, а есть только свойства. Уверяю тебя, ты быстро научишься писать на нём произвольные программы.
GZ>Если ты проектируешь(развиваешь) проект от данных — то может быть и полезно. Если от действий пользователя(как я) — то я не нахожу здесь плюсов. Покамест никакого плюса, кроме адресуемости данных, я не вижу.
Ну приведи пример "действия пользователя", которое невозможно выразить в терминах получения\изменения состояния.

GZ>Ито, это плюс достаточно абстрактный, так как за эту фичу мне денег не заплатят. По сравнению с более развитым интерфейсом — REST, это самоограничение.
Если провести строгое разделение "действий" между командами и запросами (Query-Command Separation), то у тебя как раз получится недо-REST (фактически два типа запросов будут участвовать — GET и POST). REST как раз помогает сблизить "состояние" и "действия".