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

ВВ>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

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

ВВ>Значит, пора избавляться от неверных представлений. 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?

Здравствуйте, 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 и пр., которые — уж не знаю, насколько ты их считаешь удачными — весьма широко применяются в индустрии. Или тебе ссылки привести?

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

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

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

Здравствуйте, 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.

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

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

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