Ответ 1

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

Вместо того, чтобы случайно использовать URL-адреса и URL-адреса получателей и использовать GET для всех геттеров и POST для всех сеттеров, мы пытаемся идентифицировать ресурсы URL-адресов, а затем использовать действия HTTP GET, POST, PUT и DELETE, чтобы сделать для них материал. Поэтому вместо

GET /get_article?id=1
POST /delete_article   id=1

Вы бы сделали

GET /articles/1/
DELETE /articles/1/

И затем POST и PUT соответствуют операциям "создать" и "обновить" (но никто не согласен с какими способами).

Я думаю, что аргументы кэширования неверны, потому что строки запросов обычно кэшируются, и, кроме того, вам не нужно их использовать. Например, django делает что-то подобное очень просто, и я бы не сказал, что это REST:

GET /get_article/1/
POST /delete_article/     id=1

Или просто включите глагол в URL:

GET /read/article/1/
POST /delete/article/1/
POST /update/article/1/
POST /create/article/

В этом случае GET означает что-то без побочных эффектов, а POST означает что-то, что изменяет данные на сервере. Я думаю, что это, возможно, немного яснее и проще, тем более, что вы можете избежать всего тэга PUT -vs- POST. Кроме того, вы можете добавить больше глаголов, если хотите, так что вы не искусственно к тому, что предлагает HTTP. Например:

POST /hide/article/1/
POST /show/article/1/

(или что-то еще, трудно думать о примерах, пока они не произойдут!)

Итак, в заключение я вижу только два преимущества:

  • Ваш веб-API может быть более понятным и понятным.
  • При синхронизации данных с веб-сайтом, вероятно, проще использовать REST, потому что вы можете просто сказать synchronize("/articles/1/") или что-то еще. Это сильно зависит от вашего кода.

Однако я думаю, что есть некоторые довольно большие недостатки:

  • Не все действия легко сопоставляются с CRUD (создавать, читать/извлекать, обновлять, удалять). Возможно, вы даже не имеете дело с ресурсами типа объекта.
  • Это дополнительные усилия для сомнительных преимуществ.
  • Путаница относительно того, какими кругами являются PUT и POST. На английском они означают похожие вещи ( "Я собираюсь поставить/разместить уведомление на стене".).

Итак, в заключение я бы сказал: если вы действительно не хотите приложить дополнительные усилия или если ваша служба действительно хорошо отображает операции CRUD, сохраните REST для второй версии вашего API.

Изменить

Я только что столкнулся с другой проблемой с REST: в одном запросе нелегко сделать несколько вещей или указать, какие части сложного объекта вы хотите получить. Это особенно важно на мобильных устройствах, где время туда и обратно может быть значительным, а соединения ненадежны. Например, предположим, что вы получаете сообщения на временной шкале facebook. "Чистый" путь REST был бы чем-то вроде

GET /timeline_posts     // Returns a list of post IDs.
GET /timeline_posts/1/  // Returns a list of message IDs in the post.
GET /timeline_posts/2/
GET /timeline_posts/3/
GET /message/10/
GET /message/11/
....

Какое смехотворное. Facebook API очень хорош IMO, поэтому давайте посмотрим, что они делают:

По умолчанию большинство свойств объекта возвращаются при выполнении запроса. Вы можете выбрать поля (или соединения), которые вы хотите вернуть с помощью параметр запроса полей. Например, этот URL-адрес будет возвращать только id, имя и изображение Бена: https://graph.facebook.com/bgolub?fields=id,name,picture

Я понятия не имею, как бы вы сделали что-то подобное с REST, и если бы вы сделали это, все равно считали бы REST. Я бы, конечно, проигнорировал всех, кто пытается сказать вам, что вы не должны этого делать (особенно, если причина "потому что это не REST" )!

Ответ 2

Проще говоря, REST означает использование HTTP так, как оно должно быть.

Взгляните на Рой Филдинг о REST. Я думаю, что каждый человек, занимающийся веб-разработкой, должен его прочитать.

В качестве примечания, Рой Филдинг является одним из ключевых драйверов HTTP-протокола.

Чтобы назвать некоторые из преимуществ:

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

Ответ 3

Проще говоря: НЕТ.

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

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

1. Простой

С REST вам нужен дополнительный уровень связи для ваших серверных и клиентских скриптов = > он на самом деле более сложный, чем использование не-REST HTTP.

2. Кэширование

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

3. Организация

REST не помогает . Он заставляет использовать API, поддерживаемый библиотекой на стороне сервера, которую вы используете. Вы можете организовать свое приложение таким же образом (или лучше), когда используете не-REST-подход. Например. см. Model-View-Controller или маршрутизация MVC.

4. Простота использования/внедрение

Не совсем. Все зависит от того, насколько хорошо вы организуете и документируете свое приложение. REST не волшебным образом сделает ваше приложение лучше.

Ответ 4

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

Ответ 5

Я рекомендую взглянуть на Райана Томайко Как я объяснил REST моей жене

Редактирование третьей стороны

Выдержка из ссылки waybackmaschine:

Как насчет примера. Вы учитель и хотите управлять учениками:

  • какие классы theyre,
  • какие оценки получают theyre,
  • аварийные контакты,
  • информация о книгах, которые вы преподаете, и т.д.

Если системы основаны на веб-интерфейсах, то они, вероятно, являются URL-адресом для каждого из существительных, участвующих здесь: student, teacher, class, book, room, etc.... Если бы для каждого URL было машиночитаемое представление, тогда было бы тривиально защелкивать новые инструменты в системе, потому что вся эта информация будет потребляться стандартным образом.... вы могли бы создать общенациональную систему, которая смогла бы поговорить с каждой из отдельных школьных систем для сбора результатов тестирования.

Каждая из систем будет получать информацию друг от друга с помощью простого HTTP GET. Если одной системе необходимо добавить что-то в другую систему, она будет использовать HTTP POST. Если система хочет что-то обновить в другой системе, она использует HTTP PUT. Осталось только выяснить, как будут выглядеть данные.

Ответ 6

Discoverability

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

Совместимость с другими инструментами

Вы можете использовать CURL в любой части API или использовать веб-браузер для навигации по ресурсам. Упрощает интеграцию отладки и тестирования.

Стандартизированные имена глаголов

Позволяет указать действия без необходимости поиска правильной формулировки. Представьте себе, что получатели и сеттеры OOP не были стандартизированы, а некоторые использовали вместо retrieve и define. Вам нужно будет запомнить правильный глагол для каждой отдельной точки доступа. Зная, что существует только горстка глаголов, проблема в этой проблеме.

Стандартизованный статус

Если вы GET ресурс, который не существует, вы можете получить ошибку 404 в RESTful API. Контрастируйте его с API не-RESTful, который может вернуться {error: "Not found"}, завернутый в Бога, знает, сколько слоев. Если вам нужно дополнительное пространство для написания сообщения разработчику с другой стороны, вы всегда можете использовать тело ответа.

Пример

Представьте себе два API с одинаковой функциональностью, один из которых - REST, а другой - нет. Теперь представьте себе следующие клиенты для этих API:

RESTful:

GET /products/1052/reviews
POST /products/1052/reviews       "5 stars"
DELETE /products/1052/reviews/10
GET /products/1052/reviews/10

HTTP:

GET /reviews?product_id=1052
POST /post_review?product_id=1052                  "5 stars"
POST /remove_review?product_id=1052&review_id=10
GET /reviews?product_id=1052&review=10

Теперь подумайте о следующих вопросах:

  • Если первый вызов каждого клиента работал, как вы можете быть уверенным, что все остальное тоже будет работать?

  • Было значительное обновление API, который мог или не мог изменить эти точки доступа. Сколько документов вы должны будете перечитать?

  • Можете ли вы предсказать возврат последнего запроса?

  • Вы должны отредактировать обзор, опубликованный (перед удалением). Можете ли вы сделать это, не проверив документы?

Ответ 7

Я бы предложил всем, кто ищет ответ на этот вопрос, пройдите это "слайд-шоу" .

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

Ответ 8

Кэширование.

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

Ответ 9

Это записано в Филдинг-диссертации. Но если вы не хотите много читать:

  • увеличенная масштабируемость (из-за ограничений безстоящих, кэшированных и многоуровневых систем)
  • развязанный клиент и сервер (из-за ограничений безстоящих и унифицированных интерфейсов)
    • многоразовые клиенты (клиент может использовать общие REST-браузеры и семантику RDF, чтобы решить, для какой ссылки следовать и как отображать результаты)
    • нераскрывающиеся клиенты (клиенты ломаются только по изменениям семантики конкретного приложения, потому что они используют семантику, а не некоторые специфические знания API)

Ответ 10

  • Дайте каждому "ресурсу" идентификатор
  • Свяжите вещи вместе.
  • Использовать стандартные методы
  • Ресурсы с несколькими представлениями
  • Общаться без обязательств

Можно делать все как раз с помощью POST и GET? Да, это лучший подход? Нет почему? потому что у нас есть стандарты. Если вы еще раз подумаете, можно было бы сделать все, используя GET. Так почему же нам даже нужно использовать POST? Из-за стандартов!

Например, сегодня, думая о модели MVC, вы можете ограничить свое приложение ответом только на определенные типы глаголов, таких как POST, GET, PUT и DELETE. Даже если под капотом все подражает POST и GET, не имеет смысла иметь разные глаголы для разных действий?

Ответ 11

Обнаружение в REST намного проще. У нас есть документы WADL (похожие на WSDL в традиционных веб-сервисах), которые помогут вам рекламировать ваш сервис миру. Вы также можете использовать открытия UDDI. С традиционными HTTP POST и GET люди могут не знать ваши запросы на сообщение и схемы ответа, чтобы позвонить вам.

Ответ 12

Одно из преимуществ заключается в том, что мы можем обрабатывать XML-документы без необходимости последовательно обрабатывать XML-данные из разных источников, таких как объект InputStream, URL-адрес, DOM node...

Ответ 13

@Timmmm, о вашем редактировании:

GET /timeline_posts     // could return the N first posts, with links to fetch the next/previous N posts

Это значительно сократит количество вызовов

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

Но это детали.

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

Что касается вашего замечания

"Не все действия легко сопоставляются с CRUD (создавать, читать/извлекать, обновлять, удаление)".

: RDBMS также использует CRUD-подход (SELECT/INSERT/DELETE/UPDATE), и всегда существует способ представления и использования модели данных.

Что касается вашего предложения

"Возможно, вы даже не имеете дело с ресурсами типа объекта"

: дизайн RESTful, по сути, простой дизайн, но это НЕ означает, что проектирование просто. Вы видите разницу? Вам нужно будет много думать о концепциях, которые ваше приложение будет представлять и обрабатывать, что должно быть сделано им, если хотите, чтобы представить это с помощью ресурсов. Но если вы это сделаете, вы получите более простой и эффективный дизайн.

Ответ 14

Строки запроса могут игнорироваться поисковыми системами.