Государственная сеть API: Что разработчики предпочитают использовать?
У нас есть набор данных, которые мы хотели бы выставить миру, размещенному на веб-сайте asp-net.mvc. Я хотел бы удостовериться, чтобы мы поставили его с помощью технологии, которая легка для разработчиков конца реализовать и не связанная с какой-то конкретной платформой, вместо того, чтобы использовать технологию, которая непопулярна/несовместимая у разработчиков.
Вид запросов, которые мы ожидаем, должен главным образом получить результаты поиска (не много параметров), но вниз подобное, которое мы хотели бы смочь обеспечить поискам каталога и т.п., которые могут быть более сложными.
Мысль об этом, каковы предпочтительные средства выполнения этого?
4 ответа
Windows Communication Foundation можно использовать для создания как служб SOAP (отлично, если вашими потребителями являются предприятия, использующие Visual Studio / .NET или Java), так и служб REST (для людей на других платформах). Это предпочтительные способы раскрытия общедоступных API.
Если вы хотите максимальной открытости, вероятно, лучше всего использовать подход REST, поскольку его легче использовать из «веб-языков», таких как JavaScript. У Microsoft есть обширные ресурсы по созданию REST API с использованием WCF.
Честно говоря, для тех запросов, которые, по вашему мнению, вам необходимо обрабатывать, которые, похоже, ищут данные, а не изменяют их, разница почти тривиальна - вы можно переключиться с SOAP на REST, просто изменив несколько атрибутов / параметров конфигурации, и вы можете технически даже разместить их одновременно, используя очень мало дополнительного кода. Пока вы придерживаетесь WCF и не используете устаревшие технологии, такие как ASMX / WSE, все будет в порядке.
Причины использования REST:
- Потребляемый контент практически из любого места (включая JavaScript, RSS-ридеры и т. Д.);
- Он популярен (используется в Google, Twitter и т. Д.)
- Поддерживает множество различных форматов данных (JSON, Atom и т. Д.)
Причины использования SOAP:
- Стандартизированный протокол безопасности (шифрование, предотвращение отказа и т. Д.)
- Распределенные транзакции
- Очередь сообщений
Это не исчерпывающий список но он должен дать вам представление о том, какие рынки являются целевыми для каждого из них. Если вы размещаете очень открытый, общедоступный сайт, предназначенный для всех и каждого, используйте REST.Если служба является частью бизнес-системы и вам необходимо гарантировать надежность, безопасность и согласованность данных, вам следует использовать протокол SOAP. Выберите подходящую технологию, исходя из вашего целевого рынка.
Создайте RESTful API. Как разработчик, который часто пользуется веб-сервисами, я ожидаю и предпочитаю именно этого.
Многие популярные службы (digg / twitter / netflix / google) переходят на REST вместо SOAP , так что вам будет разумно последовать их примеру.
Если вы действительно создаете REST API, вы также должны создать файл WADL . Это WISDL для REST. Они пока недостаточно поддерживаются, но их несложно создать, и они станут более полезными по мере увеличения поддержки.
Вам стоит заглянуть на сайт odata. Посмотрите на odata.org и live.visitmix.com/videos. Это даст вам REST доступ, поддержку метаданных, как в SOAP, совместимость со всем офисным стеком, и если вы используете WCF Data Services, вы сможете реализовать это за несколько часов, максимум дней.
Взгляните на netflix.com, они сделали это правильно (IMHO).