Веб-сервисы или пользовательский протокол? - PullRequest
3 голосов
/ 24 сентября 2008

У меня нет опыта работы с веб-сервисами. Исторически я создавал клиент-серверные системы, используя собственные протоколы связи (даже если они оказались XML) Я просто потратил несколько часов, глядя на Axis2, и это вызвало у меня дрожь. Кривая изучения WS меня пугает, и видя, что весь XML окружает так мало функциональности, я задаюсь вопросом, стоит ли эта проблема.

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

Пожалуйста, оставьте четкое руководство, а не мнение:)

Ответы [ 8 ]

4 голосов
/ 24 сентября 2008

Создание веб-API RESTful; тогда вы получите множество преимуществ автоматического кэширования и т. д., которые вы не получите, если будете использовать другие методы (SOAP, XML-RPC и т. д.)

См. этот пост для более подробной информации

Еще одним преимуществом является то, что если вы создаете API-интерфейс RESTful для своего кода, вы можете потенциально позволить своим пользователям также воспользоваться им - они часто используют для вашего продукта то, о чем вы никогда не мечтали.

1 голос
/ 24 сентября 2008

Я бы всегда использовал пользовательские форматы данных как последнее средство, а не первое. Какой широко используемый метод вы используете, зависит от вас, но вряд ли вы ошибетесь с моделью веб-сервисов.

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

1 голос
/ 24 сентября 2008

Помните, что существует ряд платформ, которые делают программирование веб-сервисов очень простым делом. В мире VB / C # .Net делает это радостью. Я не совсем уверен насчет конкретных фреймворков для других языков, но уверен, что у большинства есть хотя бы один.

Стандартизация и простота внедрения и повторного использования веб-сервисов делают их очень привлекательными. Как указывалось ранее, да, они делают общение очень многословным. Если вы беспокоитесь об этом, почему бы не рассчитать, сколько данных вы на самом деле будете передавать. скорее всего, при нынешних скоростях сети и интернета это будет тривиально - даже с накладными расходами XML.

1 голос
/ 24 сентября 2008

«Веб-сервисы» в соответствии с определением W3C означает использование SOAP через HTTP. SOAP в большинстве случаев является серьезным излишним; это действительно уместно (IMO), когда вы делаете общедоступную услугу доступной всему миру, например, API для взаимодействия с вашим сайтом.

Все остальное (особенно внутренние, частные коммуникации) редко нуждается в чем-то более сложном, чем XML-RPC. Только если производительность является проблемой, вы должны рассмотреть более сжатый протокол; XML-RPC настолько прост и широко поддерживается, что простота разработки и отладки более чем компенсирует потерю производительности при использовании раздувного старого XML.

0 голосов
/ 24 сентября 2008

SOAP и XML - «все то, что окружает XML, так мало функциональности, заставляет меня задуматься, стоит ли это хлопот».

Полностью. SOAP имеет большой вес и - в значительной степени - обходной путь к необходимости статического связывания во всем стеке технологий Java.

REST, с другой стороны, намного легче. Кроме того, REST с JSON или REST с YAML очень легок и очень прост в реализации. Он строится прямо поверх готового HTTP-протокола.

REST требует, чтобы вы определяли ресурсы (названные через URI) и транзакции на основе канонических правил CRUD (GET, POST, PUT и DELETE). Очень простой и канонический.

0 голосов
/ 24 сентября 2008

По моему личному мнению (старый чокнутый чувак), веб-службы должны использоваться только для того, чтобы сделать часть вашей внутренней информации доступной для третьих сторон (то есть для других компаний, людей вне вашей организации и т. Д.). Конечно, это также изначально предназначенная цель XML. : -)

Если у вас есть доступ к прямому соединению с базами данных, содержащими информацию, необходимую вашему приложению, - это путь. Это быстрее и проще - что при разработке приложений означает «лучше» и «меньше ошибок».

0 голосов
/ 24 сентября 2008

Веб-сервисы имеют то преимущество, что они несколько стандартны, поэтому программы, о которых вы никогда не слышали, могут использовать веб-сервис, написанный вами. Использование HTTP может помочь им общаться через прокси-серверы и другие сетевые препятствия без дополнительной работы с вашей стороны. XML, хотя и довольно многословный и некрасивый, его легче читать при отладке, чем двоичные данные.

При передаче данных по сети маловероятно, что сериализация / десериализация в xml будет ограничивающим фактором в производительности. Это может быть немного хлопотно, хотя библиотека, которая сделает это для вас, очень поможет.

0 голосов
/ 24 сентября 2008

Я недавно сломал свою привычку протокола. Сейчас я использую Apache на стороне сервера и libCurl плюс libxml2 для загрузки и анализа XML на клиенте, написанном на C ++.

На стороне сервера может быть либо PHP, либо CGI, написанный на более серьезном языке. Зависит от того, что вы хотите сделать.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...