Я знаю, что сайты, подобные Facebook, теперь используют службы REST, но я задаюсь вопросом о других приложениях, которые используют REST, и если есть конкретные ситуации, когда использование REST более оправданно, чем другие методологии.
Каковы наилучшие виды использования услуг REST?
Ответ 1
REST не относится к службам данных CRUD. Да, вы можете использовать REST для выполнения подобных CRUD-сервисов, но это похоже на высказывание "Регулярные выражения" для анализа адресов электронной почты.
Здесь - лучшая презентация, которую я видел в опросах REST и SOAP/RPC.
REST гораздо более ориентирован на решение распределенного взаимодействия клиент/сервер, чем с взаимодействием между сервером и сервером. REST - это получение контента перед пользователем, чтобы они могли выбирать, что с ним делать. REST не собирается создавать слой доступа к данным на основе Http, чтобы отделить вашу прикладную логику от хранилища данных.
Atom Pub - хорошая реализация REST. API Netflix является одним из лучших коммерческих REST-приложений. API Twitter не справляется с большинством ограничений RESTful.
Если вам нужна точная информация о REST, перейдите в эти места:
- http://roy.gbiv.com/untangled/
- http://tech.groups.yahoo.com/group/rest-discuss/
- http://www.innoq.com/blog/st/
- http://www.infoq.com/
Не слушайте крупных продавцов по этому предмету, они больше заинтересованы в том, чтобы сделать их существующие продукты модным словом.
Последующий:
Есть несколько причин, по которым я считаю, что интерфейсы REST более подходят для взаимодействия клиент/сервер, чем взаимодействия между серверами и серверами. Это только мое мнение, и я не пытаюсь утверждать, что эту перспективу придерживают все, кроме меня!
Отношение "многие к 1"
Преимущества кеширования и сервера без состояния становятся намного более очевидными, когда вы поддерживаете доступ многих клиентов к одному серверу. Связь между сервером и сервером часто составляет 1-1 и редко имеет большое количество серверов, взаимодействующих с одним сервером.
Свободная муфта
REST - все о свободной связи. Идея состоит в том, что вы можете продолжать развивать сервер без необходимости обновления клиентов. Если вы планируете внедрить службу REST на сервере A, которая будет вызываться сервером B, находящимся в одной комнате, тогда преимущества свободной связи уменьшаются. Он не собирается убивать вас, чтобы обновить часть программного обеспечения на обеих машинах.
гипермедиа
Ограничение гипермедиа - это предоставление пользователям выбора на основе текущего состояния приложения. Интерфейсы REST поддерживают специальную разведку гиперссылки. Связь сервера и сервера имеет тенденцию фокусироваться на достижении конкретной задачи. например Обработать эту партию данных. Выполните триггеры этих событий на основе расписания. По сути, нет никого, кто сидел бы там, принимая решения относительно того, какой путь следовать. Путь предопределен на основе параметров и условий.
Производительность
В сценарии связи сервер-сервер может потребоваться максимальная пропускная способность. Бинарный протокол может быть более подходящим, чем Http. Задержка может иметь решающее значение для типа связи сервера с сервером. В среде клиент-сервер, где один конец управляется человеком, требования к производительности совершенно разные, и я считаю, что ограничения REST более подходят для такого типа взаимодействия.
Interoperability
REST рекомендует использовать стандартные медиа-типы в качестве полезных данных HTTP. Это стимулирует повторное использование предоставляемых услуг. Я думаю, что есть много возможностей для повторного использования сервисов, предназначенных для использования клиентскими приложениями, чем те, которые предназначены для других серверов.
При разработке интерфейсов REST мне нравится думать, что потребитель сервиса - это часть программного обеспечения, которое находится под прямым контролем конечного пользователя. Не случайно веб-браузер называется User-Agent.
Ответ 2
SOAP - самая популярная альтернатива REST, и я нашел несколько хороших ссылок, описывающих их различия, и когда использовать:
Суть его в том, что REST намного проще, чем его альтернативы (особенно SOAP), и его следует использовать, когда все, что вам нужно, это базовые функции (создание/чтение/обновление/удаление), а ваш сервис не имеет статуса.
Если вы хотите использовать пример приложения, использующего REST, CouchDB. (Я не могу думать о каких-либо других членах моей головы.) Кроме того, многие сайты используют его, например Flickr, del.icio.us, Bloglines и Technorati.
Ответ 3
Есть много примеров. GData и Atom Pub Protocol, вероятно, самые лучшие. У Twitter, похоже, есть хороший REST API. Услуга Amazon S3 также довольно "RESTful". К сожалению, многие службы, которые утверждают, что RESTful нарушают самые основные принципы REST, изложенные Роем Филдингом в его dissertation, который описывал Архитектурный стиль REST.
REST - это архитектурный стиль, а не набор в определенном стандарте или реализации. Это затрудняет говорить, что такое и не является услугой REST, поэтому вы часто слышите "RESTful".
REST может быть отличной (и простой) альтернативой SOAP, XMLRPC, а в некоторых случаях таких вещей, как DCOM и CORBA. Это может быть очень простой способ облегчить основные распределенные вычисления и простой способ разоблачить API... особенно из-за того, что он так хорошо интегрируется в вездесущий HTTP.
Ответ 4
Есть LOTS интерфейсов REST: flickr и API данных Google приходят на ум как два больших примера.
REST отлично подходит для простого взаимодействия данных и соединений без состояния (аналогично самому HTTP). SOAP является распространенной альтернативой и часто используется для более сложных соединений. REST очень популярен в эти дни и является хорошим местом для начала, если вы просто изучаете, почему вы хотите иметь интерфейс данных. Проектирование интерфейсов REST легко узнать и имеет низкие барьеры для входа.
Ответ 5
Вы должны подумать о том, чего хотят ваши клиенты! Создание большой службы SOAP, которую никто не хочет потреблять, будет пустой тратой времени. Точно так же, если ваши потенциальные пользователи будут погружены в SOAP, возможно, это то, что вы должны дать им.
Если вы не знаете, чего хотят ваши пользователи, рассмотрите мнение отрасли. Большинство компаний, которые в настоящее время публикуют публичный API, предоставляют API REST. Мне очень нравится, как Foursquare задокументировал их: https://developer.foursquare.com/overview/
Ответ 6
REST эффективен, когда вашей конечной целью данных являются операции CRUD, обычно в веб-интерфейсе, обычно с использованием AJAX, Flash, Silverlight, когда безопасность, шифрование, транзакции не являются проблемой, однако, если ваши требования включает в себя любые предприятия, такие как функции, упомянутые ранее (транзакции, шифрование, совместимость и т.д.). SOAP - это решение.