Почему мы должны использовать REST?

Question

Зачем мне использовать REST, если я могу выполнять свою работу только с почтой и получать запросы?

Answer 1

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

REST требует использования гипертекста, который очень хорошо масштабируется, поскольку клиент и сервер очень слабо связаны.При использовании REST сервер может свободно изменять доступные ресурсы по своему усмотрению.За пределами того, что определяет сам REST, не существует фиксированного API.Клиенту нужно знать только начальный URI, и впоследствии он выбирает из предоставленных сервером вариантов для навигации или выполнения действий.Сервер может загрузить клиенту код, который помогает в навигации и представлении состояния.

Все это резко контрастирует с различными схемами удаленного вызова процедур (RPC), в которых клиент и сервер должны согласовать подробноепротокол, который обычно должен быть скомпилирован в оба конца (например, URI определенной формы, доступ к которым осуществляется в определенном порядке с одной стороны, SOAP / WSDL / WS * с другой).Этот подход хрупок, потому что любые изменения должны быть реализованы как на стороне сервера, так и на стороне клиента одновременно.Это быстро становится несостоятельным по мере роста количества серверов и / или клиентов.В частности, серверы страдают, потому что эволюция опубликованного API становится все сложнее с ростом популярности.

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

Но как насчет части «когда это возможно»?REST работает лучше всего, когда в цикле есть человек.В конце концов, у человека есть все шансы сделать рациональный выбор, если ему предложен ранее неизвестный набор опций.Машины еще не там.Протоколы Web RPC были созданы именно для того, чтобы наручники обеих сторон фиксировали протокол.Это упрощает взаимодействие автоматизированных процессов, когда человек удален с картинки.RPC - это правильный выбор проекта, когда чисто автоматизированная работа важнее эволюции и масштабируемости (во времени в Интернете и в масштабе Интернета).

Масштабирование и соединение?

«Масштаб» здесь подразумевается в широком смысле.Да, включает количество пользователей и сеансов, а также размер приложения и процесс разработки.Плотное соединение представляет серьезное препятствие для размера приложения.Трудно представить существование крупнейшего известного приложения, Всемирной паутины, без чрезвычайно слабой связи, обеспечиваемой архитектурой REST.Миллионы разработчиков по всему миру объединились для создания этого приложения, которое поддерживает миллиарды пользователей.Тем не менее, разработчики делают это, оставаясь блаженно не осведомленными друг о друге (или, по крайней мере, они не знали бы друг о друге, если бы не StackOverflow;).

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

Answer 2

Правильное использование REST может помочь вашим системным компонентам оставаться должным образом разъединенными и в будущем их будет легче развить, чем если бы вы связали их напрямую вместе в типичном RPC-стиле. Это архитектурный выбор, который вы должны сделать исходя из потребностей своего приложения. Другие отметили некоторые технические преимущества, и их также следует учитывать.

Answer 3

REST позволяет легко развивать дизайн API.И это ключ к REST - вы создаете API.Некоторые из комментариев касались аспектов этой мысли, но на самом деле не затронули основную проблему.Когда вы имеете дело с REST, вы создаете API, который будет использоваться клиентами (или вами).Действия HTTP над ресурсами дают четкое представление клиентам о дизайне и функциональности API.Поэтому, когда мы правильно используем правильные HTTP-глаголы, мы объявляем API, стандартизированный и понятный с точки зрения клиента.

Answer 4

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

Answer 5

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

И, если вам когда-нибудь понадобится удалить объекты, DELETE будет намного легче читать по проводам и журналам, чем запрос POST, который выполняет удаление.Но веб-браузеры не могут легко отправлять HTTP-запросы с помощью глагола DELETE, так что это действительно больше для клиентов, которые вы запрограммировали самостоятельно.

Answer 6

Вы должны использовать REST из-за следующих особенностей и преимуществ:

Особенности

1. Протокол клиента / сервера без сохранения состояния : Каждый HTTP содержит всю необходимую информацию для его запуска, что означает, что ни клиенту, ни серверу не нужно запоминать какое-либо предыдущее состояние для его удовлетворения. Как бы то ни было, некоторые приложения HTTP включают в себя кэш-память. Это настраивает так называемый протокол клиент-кэш-сервер без сохранения состояния: можно определить некоторые ответы на конкретные HTTP-запросы как кэшируемые, чтобы клиент мог запускать тот же ответ для идентичных запросов в будущем. Однако тот факт, что опция существует, не означает, что она наиболее рекомендуется.
2. В любой REST-системе и спецификации HTTP есть четыре очень важные транзакции данных: POST (создание), GET (чтение и консультирование), PUT (редактирование) и DELETE.
3. Объекты в REST всегда управляются из URI . Это URI и никакой другой элемент, который является единственным идентификатором каждого ресурса в этой системе REST. URI позволяет нам получить доступ к информации, чтобы изменить или удалить ее, или, например, сообщить ее точное местоположение третьим лицам.
4. Унифицированный интерфейс : для передачи данных система REST применяет специальные действия (POST, GET, PUT и DELETE) к ресурсам при условии, что они идентифицируются с помощью URI. Это облегчает получение единого интерфейса, который систематизирует процесс с информацией.
5. Система слоев : иерархическая архитектура между компонентами. Каждый слой имеет функциональность в системе REST.
6. Использование гипермедиа : гипермедиа - это термин, введенный Тедом Нельсоном в 1965 году, и является расширением концепции гипертекста. Эта концепция, используемая для разработки веб-страниц, позволяет пользователю просматривать набор объектов по ссылкам HTML. В случае REST API концепция гипермедиа объясняет способность интерфейса разработки приложений предоставлять клиенту и пользователю адекватные ссылки для выполнения определенных действий с данными.

Преимущества

1. Разделение между клиентом и сервером : протокол REST полностью отделяет пользовательский интерфейс от сервера и хранилища данных. Это имеет некоторые преимущества при разработке. Например, он улучшает переносимость интерфейса с другими типами платформ, увеличивает масштабируемость проектов и позволяет независимо развивать различные компоненты разработок.
2. Видимость, надежность и масштабируемость . Разделение между клиентом и сервером имеет одно очевидное преимущество: каждая команда разработчиков может масштабировать продукт без особых проблем. Они могут мигрировать на другие серверы или вносить любые изменения в базу данных, если данные каждого запроса отправляются правильно. Разделение облегчает размещение передней и задней частей на разных серверах, и это делает приложения более гибкими для работы.
3. API REST всегда не зависит от типа платформы или языков : API REST всегда адаптируется к типу используемого синтаксиса или платформ, что дает значительную свободу при изменении или тестировании новых сред в рамках развитие. С REST API вы можете иметь серверы PHP, Java, Python или Node.js. Единственное, что необходимо, чтобы ответы на запросы всегда происходили на языке, используемом для обмена информацией, обычно в XML или JSON.

Источник

Answer 7

Вам следует использовать REST, потому что он действительно охватывает все потенциальные действия, которые вы хотите выполнить с ресурсом / объектом.

• GET - получение ресурса на основе заданных условий
• POST- создать ресурс
• PUT - обновить ресурс с заданными обновленными атрибутами
• DELETE - удалить ресурс

Другая причина в том, что это стандарт, который каждыйможно реализовать и использовать.Чтобы узнать, почему стандартизация важна, я бы предложил прочитать это и это (это довольно забавно, но действительно помогает людям понять концепцию REST).

Answer 8

Почему вы думаете, что только использование POST и GET означает, что это не REST?

Смысл в REST заключается в том, что каждый «ресурс» имеет идентификатор ресурса, URI.Каждый URI потенциально имеет GET POST, PUT, DELETE.

• GET - получение
• POST - обновление
• PUT - создание
• УДАЛИТЬ - это удалить.

Если вы не делаете некоторые из этих вещей - например, PUT довольно редкая и потенциальная дыра в безопасности - тогда вы этого не сделаете.