Правильным ли веб-сервисы RESTFUL для повторного использования инфраструктуры?

Question

Есть один противоречие, которое я вижу при использовании веб -API (RESTFUL SERVICE) для доступа к удаленной инфраструктуре. Я был бы благодарен, если бы вы могли прокомментировать это. Рекомендация поступает из статьи "Restful Web Services против" больших "веб -сервисов: принятие правильного архитектурного решения» 1] - использовать веб -API скорее для специальной интеграции (A La 'Mashup) и быстрого прототипирования. Эмпирические исследования, проведенные в [2], показывают, что эти рекомендации следуют в сценарии повторного использования существующей информации и функциональности. Тем не менее, повторное использование инфраструктуры с веб-API не вписывается в задачу специальной интеграции. Мое впечатление скорее заключается в том, что инфраструктура обычно повторно используется в сценариях, в которых ресурсы, которые я имею, не очень хорошо масштабируются для проблемы, которую я хочу решить: большое количество данных, высокая пропускная способность, высокая параллельность. Тем не менее, Amazon предоставляет удаленный доступ к своей инфраструктуре (пространство для хранения, очереди сообщений) как через:

• Классические веб -сервисы SOAP (так называемые большие веб -сервисы) и
• Светлые веб -сервисы (так называемые веб -API).

Несмотря на то, что нет ничего писателя, используют ли клиенты (описанные в тематических исследованиях веб -сервисов Amazon), используют большие веб -сервисы или веб -API, тот факт, что Amazon предоставляет доступ к своей инфраструктуре в форме веб -API в качестве альтернативы, должен иметь смысл.

Вы знаете, что может быть их мотивацией? Знаете ли вы какие-либо случаи, когда люди повторно использовали инфраструктуру только для быстрого прототипа? Или, может быть, для тестирования? Другими словами, если я хотел бы повторно использовать инфраструктуру, предлагаемую Amazon, какой стиль API мне следует использовать мыло или отдыхать в каких примерных ситуациях?

РЕДАКТИРОВАТЬ: В этом случае в качестве инфраструктуры я имел в виду: пространство для хранения, вычислительная мощность, пропускная способность интернета. Таким образом, мне интересно, используются ли такие ресурсы в специальной интеграции.

---

1. Cesare Pautasso, Olaf Zimmermann, Фрэнк Лейманн, Служба RESTFUFUL VS. «Большие» веб -сервисы: принятие правильного архитектурного решения, стр. 805-814, Джинпенг Хуай, Робин Чен, Сяо-Вуэн Хон, Юнхао Лю, Вей-Иин М.А., Эндрю Томкинс, Сяодон Чжан (ред.), Труды 17 -й Международной конференции всемирной паутины, ACM Press, Пекин, Китай, апрель 2008 г.

2. Хартманн, Бьорн и Дорли, Скотт и Клеммер, Скотт Р., Взлом, пюре, склеивание: понимание оппортунистического дизайна, IEEE распространяется Vol. 7, нет. 3, 46-54 (2008).

Answer 1

Ключ к пониманию, какую версию использовать ложь в понимании одной вещи - если вам нужно выполнить сложные операции по Интернету с глубоко встроенными иерархиями объектов, то вы эффективно вынуждены использовать веб -сервисы. REST исключительно способен, когда дело доходит до выполнения простых операций, но сложные операции выходят за рамки его сбора.

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

Answer 2

Я думаю, что когда люди говорят об использовании существующей инфраструктуры с помощью RESTFUL WEB -сервисов, они означают, что могут использовать существующие вещи, предназначенные для Интернета, а не для использования программного обеспечения, специально созданного для веб -служб. Например, если у меня есть веб -сервис, использующий отдых, я могу воспользоваться такими вещами, как прокси HTTP Caching, где можно получить эквивалентную функциональность с мылом, мне нужно что -то специализированное.

Answer 3

Отдых бесконечно проще в использовании, чем мыло. FWIW, Google больше не использует мыло, все это отдых.

Единственное преимущество для мыла - это то, что вы получаете объекты, которые можно использовать прямо из коробки. С Rest вам либо нужна структура, такая как JAX-RS, чтобы создать эти объекты для вас, либо разобрать их вручную.

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