Comments 19
Я такое делал на основе ASP.NET MVC3.
Там это гораздо управляемей и быстрей в реализации выходит.
Легкий маппинг на урл (api.service.com/get-user/1/json)
Версионировать легко. (api.service.com/v2/get-user/2/xml);
Но подумываю переписать на WCF — в плюсах вижу:
+ разные биндинги (http, socket)
+ разные возвращаемые типы (protocol buffers, json, xml etc). Тут важно разобраться с REST Starter Kit.
Отсюда например в другой .net можно импортировать вебсервис, а Java и другие будут общаться c REST API через http & json.
Но у меня не стоит задачи переноса сервера и установки его в разных средах, он у меня крутится в облаке и все.
В вашем случае портабельность — несомненно хороший плюс.
Еще мне кажется, что пример с загрузкой и отдачей картинки — не самый удобный для демонстрации API. Обычно это отдельный низкоуровневый хэндлер для отдачи изображений и к нему совсем другие требования, чем например к выборке например пользователей.
Там это гораздо управляемей и быстрей в реализации выходит.
Легкий маппинг на урл (api.service.com/get-user/1/json)
Версионировать легко. (api.service.com/v2/get-user/2/xml);
Но подумываю переписать на WCF — в плюсах вижу:
+ разные биндинги (http, socket)
+ разные возвращаемые типы (protocol buffers, json, xml etc). Тут важно разобраться с REST Starter Kit.
Отсюда например в другой .net можно импортировать вебсервис, а Java и другие будут общаться c REST API через http & json.
Но у меня не стоит задачи переноса сервера и установки его в разных средах, он у меня крутится в облаке и все.
В вашем случае портабельность — несомненно хороший плюс.
Еще мне кажется, что пример с загрузкой и отдачей картинки — не самый удобный для демонстрации API. Обычно это отдельный низкоуровневый хэндлер для отдачи изображений и к нему совсем другие требования, чем например к выборке например пользователей.
Похоже, я упустил из вида описание самой «фишки» предлагаемого подхода. У сервера приложений всего лишь одна точка входа — "/service.ashx", никаких других хэндлеров нет и они не нужны! Этот базовый адрес с помощью несложного клиентского API, который легко пишется для любого типа клиента, динамически выстраивается в нужный url, а на сервере приложений HttpRequest превращается в вызов через Reflection соответствующего метода из указанной сборки.
В следующей статье постараюсь развить эту тему, чтобы идея была более понятна и «прочувствована» :)
В следующей статье постараюсь развить эту тему, чтобы идея была более понятна и «прочувствована» :)
Непонял в чем фишка, уже ж есть WCF Web API. Там все заимплпменченно, и УРЛЫ нормальные (service.ashx < — что это за хрень?), так как там используется System.Web.Routing.
Короче, велосипед который в теории был бы оправдан лет пять тому назад. Минусявка от меня, а то позору за платформу не обрешся.
Короче, велосипед который в теории был бы оправдан лет пять тому назад. Минусявка от меня, а то позору за платформу не обрешся.
service.ashx — хэндлер. Такие файлы, как правило, исключают из таблицы роутов. С WCF надо играться, а тут добавил файл и сервис готов — для простых кейсов можно использовать.
Я знаю что такое ashx. С роутингом, одна строка кода и без всяких файлов готов сервис. С нормальными урлами. На написание этой статьи ушло больше времени че на «играться» с WCF и роутингом.
Для затравки, это код для регисрации.
RouteTable.Routes.MapServiceRoute("Commands");
А это код сервиса.
[ServiceContract]
public class CommandsService
{
[WebGet(UriTemplate = "")]
public CommandDef Get()
{
return new CommandDef{};
}
}
... Странно да?Надо просто попробовать. Сделать WCF сервис и написать для него четыре простых клиента, как в моем примере, с вызовом всего лишь 2-х методов: GetImageInfo() и GetImage(). И посмотреть во что это выльется.
service.ashx — всего лишь фабрика обработчиков, что ненормального в url? REST стиль — это всего-лишь один из способов адресации. Суть же не в этом.
service.ashx — всего лишь фабрика обработчиков, что ненормального в url? REST стиль — это всего-лишь один из способов адресации. Суть же не в этом.
Я уже попробовал, код сразу же над вашим коментраием. Подставьте там нужные методы, а клиенты такими и остантуся, сервис вернет самый обычный JSON. Урлы будут ввиде localhost/Commands/xxxx, под хххх будет то как UriTemplate.
Более того, оно еще и принимать JSON может(уже обьектом), и формат выбирает не через урл (разве что для девелоперский целей), а правильно чере Accrpt хеадер.
Более того, оно еще и принимать JSON может(уже обьектом), и формат выбирает не через урл (разве что для девелоперский целей), а правильно чере Accrpt хеадер.
Вы лукавите, с WCF не все так просто. В Вашем шаблоне еще нет Web.config-а, метод не сможет вернуть Stream, сложные Json структуры для него не «съедобны». Добавить метод — пересобрать сервис.
К тому же WCF «зашит» как синхронный хэндлер, что вызывает подозрение в ограничениях, таких же как обработка .aspx
Ах, если бы WCF был так хорош…
К тому же WCF «зашит» как синхронный хэндлер, что вызывает подозрение в ограничениях, таких же как обработка .aspx
Ах, если бы WCF был так хорош…
1) У меня нет Web.config-а, потому что он не нужен.
2) WCF может вернуть HttpResponseMessage
Писал по памяти, но суть такова. Причем при желании в 10ть строк можно написать форматтер чтобы возвращало стрим. На самом то деле я не уверен что там Стрим неззя возвращать, это я так сказать вам верю.
3) Конешно же пересобрать. Я же нехочу чтобы кто-то мог свободно вызвать CurrentConnections(«MyaConnection») и получить стоку соединения с БД ;).
4) Что-то не понял о каких ограничениях речь. Хотя WCF Web API собсно имплементит и IHttpAsyncHandler и IHttpHandler
2) WCF может вернуть HttpResponseMessage
public HttResponseMessage GetImage(string filePath){
return new HttResponseMessage{Content = new StreamContent(File.Read(filePath))}
}Писал по памяти, но суть такова. Причем при желании в 10ть строк можно написать форматтер чтобы возвращало стрим. На самом то деле я не уверен что там Стрим неззя возвращать, это я так сказать вам верю.
3) Конешно же пересобрать. Я же нехочу чтобы кто-то мог свободно вызвать CurrentConnections(«MyaConnection») и получить стоку соединения с БД ;).
4) Что-то не понял о каких ограничениях речь. Хотя WCF Web API собсно имплементит и IHttpAsyncHandler и IHttpHandler
Такс, ради вас проверил можно ли возвращать Stream. Можно. Никаких вообще проблем:
Забыл охватить «сложные Json структуры для него не «съедобны»», вопервых, оно все что надо хавает. Даже если несхавает, подрубить JSON.NET туда, это приблизительно 8 строк кода ;), а можно просто подрубить.
public Stream GetImage(string filePath){
return File.OpenRead(filePath);
}
Забыл охватить «сложные Json структуры для него не «съедобны»», вопервых, оно все что надо хавает. Даже если несхавает, подрубить JSON.NET туда, это приблизительно 8 строк кода ;), а можно просто подрубить.
«Сложные» я имел ввиду вложенные, т.е. граф объектов.
Поддержка IHttpAsyncHandler — это гуд, потому как родной .svc — только синхронный.
Все хорошо, но разве не утомительно помимо самих методов регистрировать еще мапинги на них и каждый метод аннотировать атрибутом?
А в общем, Web API, которое Вы упомянули — хорошее дополнение к WCF, но только надо сказать, что это коммунити проект, ну типа моего :)
А подключение методов без перекомпиляции сервиса очень удобно. Пример — вы автор уже работающего сервиса, но ему нужна доп.функциональность. Можно отдать реализацию функционала другому разработчику без предоставления исходников сервиса, не все же самому писать. А вызов системных функций и из GAC конечно же блокирован.
Вы не знаете, реализована ли в Web API работа с потоковым видео и дозагрузка файлов?
Поддержка IHttpAsyncHandler — это гуд, потому как родной .svc — только синхронный.
Все хорошо, но разве не утомительно помимо самих методов регистрировать еще мапинги на них и каждый метод аннотировать атрибутом?
А в общем, Web API, которое Вы упомянули — хорошее дополнение к WCF, но только надо сказать, что это коммунити проект, ну типа моего :)
А подключение методов без перекомпиляции сервиса очень удобно. Пример — вы автор уже работающего сервиса, но ему нужна доп.функциональность. Можно отдать реализацию функционала другому разработчику без предоставления исходников сервиса, не все же самому писать. А вызов системных функций и из GAC конечно же блокирован.
Вы не знаете, реализована ли в Web API работа с потоковым видео и дозагрузка файлов?
1) Потдерижвает вложенные, я даже проверять не буду.
2) Родной .svc, может быть асинхронным, метод должен вернуть IAsyncResult
3) Конвеншен чтобы убрать атрибуты пишется на раз два три. Причем ладно там WCF, тот же ASP.NET MVC все это может (это мой старючий пост).
4) У вашего «очень удобно» даж коментировать не буду, вы че реально считате что в локальном коде неззя найти интересной инфы? Вас даже задосить будет на раз два три.
5) «видео и дозагрузка файлов» без понятия заимплеменчено ли. Быстрее всего нет. Но что-то вы многовато хотити от application server.
2) Родной .svc, может быть асинхронным, метод должен вернуть IAsyncResult
3) Конвеншен чтобы убрать атрибуты пишется на раз два три. Причем ладно там WCF, тот же ASP.NET MVC все это может (это мой старючий пост).
4) У вашего «очень удобно» даж коментировать не буду, вы че реально считате что в локальном коде неззя найти интересной инфы? Вас даже задосить будет на раз два три.
5) «видео и дозагрузка файлов» без понятия заимплеменчено ли. Быстрее всего нет. Но что-то вы многовато хотити от application server.
Прикладную сборку из Bin-а невозможно выкачать, так же как и загрузить, Вы же это знаете. А задосить можно любой сервис, это никак не связано.
Кстати, у меня реализованы виртуальные хосты, т.е. домены внутри домена самого сервера приложений. Есть админское API, через который я могу удаленно инсталлировать, запускать/останавливать и удалять приложения.
Да, именно, хочу многое, чтобы не надо было думать в ходе дальнейшей прикладной разработки, как реализовать то, что уже изначально должно быть. Поэтому — читаем еще раз тему топика, где жирными словами написано "… свой Application Server".
А Вам предлагаю написать о своей практике использования WCF Web API. Еще круче, если будет описание «внутренностей».
Кстати, у меня реализованы виртуальные хосты, т.е. домены внутри домена самого сервера приложений. Есть админское API, через который я могу удаленно инсталлировать, запускать/останавливать и удалять приложения.
Да, именно, хочу многое, чтобы не надо было думать в ходе дальнейшей прикладной разработки, как реализовать то, что уже изначально должно быть. Поэтому — читаем еще раз тему топика, где жирными словами написано "… свой Application Server".
А Вам предлагаю написать о своей практике использования WCF Web API. Еще круче, если будет описание «внутренностей».
Я вот не пойму, а как я, разработчик, узнаю какие у есть методы API у вас по вашему урлу?
Вот с WCF понятно, я подключил и знаю, какие методы у меня есть. А здесь не могу понять… Объясните?
Вот с WCF понятно, я подключил и знаю, какие методы у меня есть. А здесь не могу понять… Объясните?
Если имеется ввиду автогенерация клиентских прокси, то как правило в общедоступной среде такая возможность на сервере отключается, а прикладным разработчикам предоставляются уже готовые их реализации. Пример: все публичные веб-проекты предоставляют уже готовый клиентский API под конкретную платформу без необходимости для вас исследовать сервис на наличие методов. Мало ли какие методы есть у сервиса, вы ничего о них знать не должны в принципе. С другой стороны, вы как разработчик сервиса прекрасно знаете все о своем детище :)
Вообще в REST-парадигме сервисы не являются самодокументирующимся. Нет никакого WSDL. Если нет публичной документации, остается только уповать на то, что авторы используют HATEOAS, то есть выбрасывают назад линки на возможные дополнительные операции.
Я тут еще раз глянул в Вики по вопросу, что же такое REST. И еще больше убедился в том, что критика в мой адрес по вопросу, почему представленная реализация не подпадает под шаблон REST, не правомерна.
Sign up to leave a comment.
IIS + .NET + Json. Пишем свой Application Server