По-видимому, REST - это просто набор соглашений о том, как использовать HTTP . Интересно, какое преимущество дают эти соглашения? Кто-нибудь знает?

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

Вместо того , чтобы случайно именованный-акцессоры 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этого POST. Кроме того, вы можете добавить больше глаголов, если хотите, чтобы вы не были искусственно связаны с тем, что предлагает HTTP. Например:

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

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

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

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

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

1. Не все действия легко отображаются в CRUD (создание, чтение / получение, обновление, удаление). Вы можете даже не иметь дело с ресурсами типа объекта.
2. Это дополнительные усилия для сомнительных выгод.
3. Путаница относительно того, какой путь 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/
....

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

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

Я понятия не имею, как бы вы сделали что-то подобное с REST, и если бы вы сделали, будет ли это все равно считаться REST. Я бы, конечно, проигнорировал любого, кто пытается сказать вам, что вы не должны этого делать (особенно, если причина в том, что «это не ОТДЫХ»)!

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

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

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

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

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

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

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

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

1. Простой

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

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

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

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

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

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

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

ИМХО самое большое преимущество, которое дает REST, - это уменьшение связи клиент / сервер. Гораздо проще развивать интерфейс REST с течением времени, не нарушая существующих клиентов.

Понятность

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

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

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

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

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

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

Если ваш GETресурс не существует, вы можете быть уверены, что получите 404ошибку в RESTful API. Сравните это с не-RESTful API, который может вернуться, {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, которое могло или не могло изменить эти точки доступа. Сколько документов вы должны будете перечитать?

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

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

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

Стороннее редактирование

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

СУБД также использует подход CRUD (SELECT / INSERT / DELETE / UPDATE), и всегда есть способ представить модель данных и воздействовать на нее.

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

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

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

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