Веб-сервис против публикации формы - PullRequest
3 голосов
/ 28 апреля 2009

У меня есть 2 веб-сайта (www.mysite1.com и myweb2.com, оба сайта находятся в ASP.NET с SQL-сервером в качестве бэкэнда), и я хочу передавать данные с одного сайта на другой. веб-сервис или отправка формы (от mysite1 до страницы в myweb2)

Может кто-нибудь сказать мне плюсы и минусы обоих?

Ответы [ 6 ]

5 голосов
/ 28 апреля 2009

Под веб-службой я предполагаю, что вы имеете в виду веб-службу на основе SOAP?

В любом случае, оба равны, но имеют несколько преимуществ. Публикация более легкая, а SOAP стандартизирован (вроде). Я бы предпочел более спокойный подход, потому что я думаю, что SOAP слишком много накладных расходов для простых задач, но не дает большого преимущества.

3 голосов
/ 28 апреля 2009

Веб-сервисами являются SOAP-сообщения (протокол SOAP использует XML для передачи сообщений туда и обратно), поэтому ваш сервер на обоих концах должен понимать SOAP и любые расширения, о которых вы хотите поговорить между ними, и они, вероятно, (но не обязательно) иметь возможность получать файлы WMDL (что «объясняет» различные конечные точки служб и доступные удаленные функции). Обычно мы называем это стеком SOAP / WS- *, с акцентом на «стек», поскольку требуется несколько кусков программного обеспечения, и чем сложнее вызовы SOAP, тем больше этого стека должно быть доступно и поддерживаться. .

Использование POST, с другой стороны, в основном ассоциируется с RESTful-поведениями , и в качестве примера такого протокола рассмотрим HTTP. Внутри POST вы, конечно, можете публиковать сложные XML, но люди склонны использовать простой POST для упрощения вызова и использовать HTTP-ответы в качестве ответов. Возможно, вам не нужно никакого дополнительного программного обеспечения, поскольку большинство, если не все веб-комплекты, имеют поддержку HTTP. Мой собственный уклон склоняется к REST, если вам интересно. Используя HATEOAS, вы можете создать действительно хорошую инфраструктуру для самоосознающих систем, которые могут изменять себя с нагрузкой и доступностью в режиме реального времени, в отличие от способа SOAP, и это лежит в центре аргумента для it ; HTTP был разработан для больших распределенных сетей, имеющих дело с производительностью и стабильностью. SOAP имеет тенденцию быть универсальным, если что-то ломается, вы набиты чем-то вроде. (Опять же, помните о моей предвзятости. Я много писал об этом в своем блоге, особенно со стороны архитектуры и влияние SOA против ROA .:)

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

Я за здоровую дискуссию об этом, но я склонен думать, что SOAP - это переизобретение; SOAP - это конверт с заголовком и телом, и если это звучит знакомо, это именно то, как был разработан HTML - факт, который очень мало людей видят. HTTP как просто протокол для перемещения вещей хорошо понят и чрезвычайно хорошо поддерживается, и SOAP использует его для перемещения своих XML-конвертов. Есть ли реальная разница между смещением SOAP и HTML? Ну, да, большая разница в том, что SOAP заново изобретает все тонкости HTTP (кеширование, адресуемость, состояние, масштабирование), а затем использует HTTP только для доставки сообщения и ничего больше и позволяет самому стеку иметь дело с упомянутыми тонкостями ранее. Итак, многие достоинства HTTP игнорируются и воссоздаются на другом уровне (следовательно, вам необходим стек SOAP, чтобы справиться с ним), что мне кажется расточительным, невежественным и усложняющим.

Следующее - это то, что вы хотите сделать. Для действительно сложных вещей в стеке веб-сервисов есть множество стандартов (я думаю, что в настоящее время их объединено около 1200 страниц), которые могут вам помочь, но если ваши потребности более скромны (то есть, не , что без ума от например, серьезно сложная защита) достаточно простого POST (или GET) запроса и конверта с результатами. Результаты в HTTP - это, как вы, наверное, знаете, HTTP-тип контента, поэтому многие из них уже поддерживаются, но вы можете создать свой собственный, например application / xml + myformat (или, точнее, application / x-xml + myformat, если я правильно помню ). Получить запрос, если это код ответа 200, и разобрать.

Оба будут работать. Один из них тяжелый (стек WS- *) в зависимости от ваших потребностей, другой более легкий и уже поддерживается. Остальное, как говорится, клей.

1 голос
/ 28 апреля 2009

Я бы сказал, что веб-сервис, безусловно, лучший выбор. Несколько плюсов:

  • Если в будущем вам понадобится добавить еще один веб-сайт, ваша инфраструктура (веб-сервис) уже существует
  • Публикация форм на разных сайтах может вызвать проблемы при использовании файлов cookie или может вызвать ограничения конфиденциальности браузера
  • Если вы используете форму публикации, вы должны писать один и тот же код снова и снова опять же, используя веб-сервис вы пишете код один раз, затем используйте его в нескольких местах. Легче поддерживать, меньше кода для написать.
  • ремонтопригодность (это связано с вышеупомянутый пункт) конечно, все код, относящийся к обмену данными все в одном месте (ваш веб-сервис)

Там, наверное, даже больше. Как поддержка времени разработки / завершение кода.

0 голосов
/ 28 апреля 2009

Я согласен с Александром Йоханнесеном в том, что сомнительно, лучше ли веб-сервисы SOAP или API RESTful, однако, если оба сайта находятся под вашим контролем и работают с asp.net, обязательно используйте веб-сервисы SOAP. Инструменты, которые Visual Studio предоставляет для создания и использования веб-сервисов, просто великолепны, вам не понадобится несколько минут, чтобы создать связь между двумя сайтами.

На сайте, где вы хотите получать сообщения, создайте веб-сервис, выбрав добавить элемент в VS. Выберите веб-сервис и назовите его соответствующим образом. Затем просто создайте метод с логикой, которую вы хотите реализовать, и добавьте атрибут [WebMethod], например.

[WebMethod]
public void AddComment(int UserId, string Comment) {
  // do stuff
}

Разверните это на своем тестовом сервере, например, tst.myweb2.com.

Теперь на стороне потребителя (www.myweb1.com) выберите Добавить веб-ссылку, укажите URL-адрес по адресу только что созданного веб-сервиса, дайте ему имя и нажмите Добавить ссылку. У вас есть прокси-класс, который вы можете вызывать так же, как локальный класс. Легко, как пирог.

0 голосов
/ 28 апреля 2009

Я бы предложил веб-сервис (или WCF). Как сказала Бини, с помощью сервиса вы можете увидеть методы и типы сервиса (которые вы предоставляете), которые облегчили бы и более чистое перемещение данных.

0 голосов
/ 28 апреля 2009

Из моего небольшого опыта я бы сказал, что вам лучше всего использовать веб-сервис, так как вы можете увидеть методы и структуру сервиса в своем коде, как только вы создали его в конце получения.

Кроме того, использование методов публикации формы может привести к тому, что вам придется подделывать отправленные формы, что не так просто, как вызов веб-службы.

Ваш третий способ - заставить базы данных говорить, хотя я предполагаю, что они разрозненны и не могут "видеть" друг друга?

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