По-видимому, 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/
(Или что-то еще, трудно думать о примерах, пока они не произойдут!)
Итак, в заключение я вижу только два преимущества:
synchronize("/articles/1/")или что-то еще. Это сильно зависит от вашего кода.Однако я думаю, что есть некоторые довольно большие недостатки:
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. Я бы, конечно, проигнорировал любого, кто пытается сказать вам, что вы не должны этого делать (особенно, если причина в том, что «это не ОТДЫХ»)!
/user/{id}, тогда это не успокаивает. Подумайте: должен ли ваш браузер быть предварительно запрограммированным, зная, как получить HTML для вопроса stackoverflow» страница?
Проще говоря, REST означает использование HTTP таким, каким оно должно быть.
Взгляните на диссертацию Роя Филдинга о REST . Я думаю, что каждый, кто занимается веб-разработкой, должен это прочитать.
Как примечание, Рой Филдинг также является одним из ключевых драйверов протокола HTTP.
Чтобы назвать некоторые из преимуществ:
Проще говоря: НЕТ .
Не стесняйтесь понижать голос, но я все еще думаю, что нет никаких реальных преимуществ по сравнению с HTTP без REST. Все текущие ответы недействительны. Аргументы из наиболее популярных на данный момент ответов:
С REST вам необходим дополнительный уровень связи для сценариев на стороне сервера и на стороне клиента => на самом деле это сложнее, чем использование HTTP без REST.
Кэширование может контролироваться HTTP-заголовками, отправляемыми сервером. REST не добавляет никаких функций, отсутствующих в не-REST.
ОТДЫХ не помогает вам организовать вещи. Это заставляет вас использовать API, поддерживаемый используемой вами серверной библиотекой. Вы можете организовать свое приложение таким же образом (или лучше), когда используете подход без REST. Например, см. Model-View-Controller или MVC .
Совсем не правда. Все зависит от того, насколько хорошо вы организуете и документируете свое заявление. 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.
GET /get_article/19/и POST /update_articleесли кеширование является вашей заботой. Вы все еще можете сделать все , что только с GETи POSTи я считаю , RESTозначает «использование GET, POST, PUTи DELETEтолько.» а не просто «Не использовать строки запроса». так что я не предложил REST. С другой стороны , никто не может на самом деле согласен , что REST это так , я помещаю его в ведре с «Web 2.0».
Это записано в диссертации Филдинга . Но если вы не хотите много читать:
Можно все сделать только с помощью 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 дизайн, по сути, простой дизайн, но это НЕ означает, что проектирование это просто. Вы видите разницу? Вам придется много думать о концепциях, которые ваше приложение будет представлять и обрабатывать, что должно быть сделано им, если вы предпочитаете, чтобы представить это с помощью ресурсов. Но если вы сделаете это, вы получите более простой и эффективный дизайн.
Поисковые системы могут игнорировать строки запроса.