Привет всем!

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

Спасибо!

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

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

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

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

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

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

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

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

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

P>Спасибо!

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

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

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

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

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

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

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

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, правда в гугле моментально они нашлись в ассортименте

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

Здравствуйте, 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 — это не какой-то обновленный ремотинг, совсем.