REST vs RESTful vs «нормальный» веб-сервис - то же самое или нет?

21

Я прочитал пару определений и обсуждений по приложениям REST и / или RESTful, но я до сих пор не понимаю его истинного значения.

Я обычно работаю с приложениями, которые либо извлекают данные через GET, либо отправляют данные через POST в какой-либо веб-сервис (обычно скрипт PHP), который затем либо получает данные из базы данных, либо выполняет запись в базу данных.

Теперь это приложение RESTful? Если нет, что бы RESTful приложение? В чем разница между концепцией RESTful и концепцией, с которой я работал до сих пор? Пожалуйста, объясните на примере.

Кроме того, кто-то говорит о REST, а кто-то о приложениях RESTful. Я обнаружил, что термин REST относится к теоретической концепции, тогда как RESTful используется, когда мы говорим о конкретном приложении. Правильно ли это или есть реальные различия между приложениями REST и RESTful?

java php web-services mobile rest deviDave
источник
1
Если вы можете собрать все свои сервлеты, чтобы получать информацию только из параметров GET или POST (абсолютно ничего не сохранялось локально до вызова), то вы правильно применяете REST. Другими словами, сервер играет роль модели в MVC в том смысле, что он не контролирует, а просто использует то, что дано для выполнения какой-либо задачи. Надеюсь, это объясняет это немного лучше.
Нил
@Neil Я на другой стороне - мобильное приложение. Это клиент, который использует веб-сервис и общается с ним через POST и GET. Все веб-сервисы были созданы кем-то другим, и все, что я делал, это использовал их. Но терминология смутила меня. Итак, если я использую канал HTTP и объекты HttpGet / HttpPost, то я имею дело с приложением RESTful, верно?
deviDave
Не обязательно. Нет никакого способа узнать, является ли это приложением RESTful, если вы не знаете, как работает сервер, поскольку он может нарушать некоторые ограничения. Тем не менее, это, вероятно, RESTful, если он возвращает согласованные результаты.
Нил
@ Нил О, я понял. RESTful делается на сервере. И если я отправляю объект post с запросом (не для каждого параметра в отдельности), то это, вероятно, подход REST. Что касается клиента (мобильного приложения), его не волнует, является ли он REST или нет, так как кодирование одинаково. Я правильно понял?
deviDave
2
RESTful - это и сервер, и клиент, но если вы можете видеть только клиента, вы можете узнать только, соблюдает ли клиент ограничения. Это все, что я имел в виду. Под REST я подразумеваю, что если вам нужно войти в систему, вы должны указать имя пользователя и пароль. Сервер проверяет логин и сохраняет хэш-ключ пользователя в базе данных и возвращает его. Теперь, когда вам нужно выполнить операцию, требующую входа в систему, вы всегда передаете хеш-ключ пользователя. Сервер «забывает», что вы вошли в систему, но использует хеш пользователя для проверки вашего состояния входа. Если бы он не был RESTful, сервер запомнил бы, что вы вошли в систему. Понимаете разницу?
Нил

Ответы:

13

Ключевыми атрибутами приложений RESTful являются: Все общение происходит через http: GET, POST, PUT, DELETE, и все элементы адресуются через стандартный URL-адрес формы, http://your.site.com/salesapp/salesperson/0000001/detailsт.е. только чистый URL-адрес без параметров и т. Д. URL-адрес идентифицирует объект GET. , POST, PUT, DELETE определяет, что вы хотите с ним сделать.

Основная причина для этого заключается в том, что у вас автоматически есть служба без сохранения состояния, которая может быть сбалансирована по нагрузке, выполнена после сбоя и т. Д.

Сама простота схемы обеспечивает очень чистый интерфейс, полностью отделяющий клиента от любой конкретной серверной реализации.

Джеймс Андерсон
источник
О, пока я не использовал PUT или DELETE (мобильные приложения обычно делают только GET и POST), но это действительно похоже на то, что я делал и делаю в данный момент. Просто клиенты используют не термины REST *, а «веб-сервис» и «скрипт php»
deviDave,
2
Джеймс, не могли бы вы объяснить, почему следует избегать параметров запроса? Например, как мне выразить, что я хочу, чтобы ресурсы были отфильтрованы определенным образом без введения ложной иерархии?
Гари Роу
3
@GaryRowe: URL (без параметров) определяет ресурс, которым вы хотите манипулировать. У вас все еще могут быть параметры, но они не используются при идентификации ресурса. Пример GET для каталога (URL-адрес, заканчивающийся на /) должен возвращать список ресурсов в каталоге. Параметр в URL может быть использован для указания фильтра или порядка сортировки или чего-то подобного.
Мартин Йорк
1
Спасибо, Локи. Джеймс может захотеть отредактировать свой ответ, чтобы отразить это, поскольку кажется, что он не позволяет использовать параметры запроса ни при каких обстоятельствах, которые могут вводить в заблуждение. На самом деле, есть интересное наблюдение, что список ресурсов в каталоге сам по себе является ресурсом, выражающим эту концепцию.
Гари Роу
REST не требует, чтобы приложение было основано на URL, и при этом не требует, чтобы у вас были глаголы, такие как GET, POST, DELETE и т. Д. Однако для WebApp URL является единственным вариантом и вышеупомянутыми глаголами.
Наваз
6

REST расшифровывается как представительский государственный трансфер. Если ваше программное обеспечение соответствует ограничениям REST, оно считается RESTful.

Хорошо, теперь, когда я бесстыдно вырвал из Википедии, что это на самом деле означает? Это фактически означает использование встроенных команд HTTP, таких как GET, POST, PUT, DELETE и несколько других, более редких, для обмена данными между клиентом и сервером.

То, что вы делаете, звучит как приложение RESTFul. Тем не менее, есть большая разница между хорошо разработанными и ненужными веб-сервисами RESTFul. Например, PHP-код на другом конце GET может выполнять изменение состояния, что считается неправильным, поскольку GET рассматривается как операция только для чтения. Существуют тонкие различия между тем, как используются POST (новый) и PUT (замена).

Статья в Википедии действительно хороша, поэтому я на этом остановлюсь.

Мартейн Вербург
источник
До сих пор я использовал GET (HttpGet) для извлечения содержимого и POST (HttpPost) для ввода / изменения содержимого базы данных. Я отправил это как параметр в HttpPost, а PHP-скрипт на веб-сервере преобразовал эти параметры в код SQL. Это RESTful приложение? Меня интересует концепция, а не то, насколько хорошо был написан PHP-скрипт. Я не сделал это.
deviDave
2
Я бы исследовал использование PUT в случае замены контента, это более идиоматический REST, чем всегда использование POST.
Мартейн Вербург
Да, в таком случае я бы использовал PUT.
deviDave
+1 за то, что GET должен быть реализован правильно (т.е. он идемпотентен). Такая фундаментальная ошибка в первые дни.
Гари Роу
@deviDave Вы также можете посмотреть PATCH, который предназначен для обновления части ресурса. Как справедливо отмечает Мартин, PUT предназначен для замены всего ресурса.
Гари Роу
4

Прежде чем идти дальше, этот связанный вопрос может помочь вам

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

Многие веб - приложения утверждают, что RESTful, но на самом деле лишь частично согласованные с к REST Ограничений (как Мартейн Вербург также ссылается в своем ответе). Я просто перечислю их здесь, но я настоятельно призываю вас прочитать статью:

  • Клиент-сервер
  • Cacheable
  • Многоуровневая система
  • Код по запросу (необязательно)

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

Ваш клиент должен будет:

  • использовать HTTP-глаголы (например, GET, POST, PUT, DELETE, OPTIONS, PATCH) для выполнения соответствующих операций
  • предлагать заголовки Accept и понимать заголовки Content-Type (например, вы получаете XML, который вы никогда раньше не видели, но вы можете использовать ссылочный XSD для создания модели домена на стороне клиента для представления вашему пользователю)
  • перейдите по предлагаемым ссылкам в понятном вам типе контента (например, попросите пользователя или ваше приложение сделать вывод, что <link rel="pay" href="http://example.org/orders(1)/payment">в HTML выражается переход состояния для создания ресурса платежа через POST с телом, содержащим некоторый XML-код, представляющий детали платежа, например номер кредитной карты , количество и так далее)
  • правильно реагировать на широкий спектр кодов состояния HTTP

Если он делает вышеупомянутое, то его можно рассматривать как клиента REST, вы можете назвать его «приложением RESTful», но это скорее будет означать, что вы используете REST на стороне клиента, что неверно, поэтому лучше избегать срок.

Гэри Роу
источник
3

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

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

Ян Худек
источник
Upvote для 1-го абзаца. Так кратко. Благодарность!
deviDave
Ты еще одна вещь, чтобы увидеть, правильно ли я понял. Если я (мое приложение) являюсь клиентом службы REST, я как клиент не рассматриваю, является ли служба RESTful или нет, поскольку мое кодирование всегда одинаково (httpget, httppost и т. Д.)? Этот принцип имеет значение только для владельца серверного скрипта / приложения?
deviDave
REST - это руководство для разработки семантики интерфейса. Базовой технологией является HTTP, независимо от того, является ли интерфейс RESTful или нет (но другие уровни, такие как XML-RPC или SOAP, не имеют отношения к интерфейсам RESTful), поэтому вы всегда используете один и тот же httpget, httppost и т. Д. Но вы обрабатываете сбои сети по-разному.
Ян Худек
добавим, что SMTP - это интерфейс RESTful, хотя он использует разные глаголы из GET, PUT и т. д. и другой базовый протокол, концепция та же - вы отправляете команды на основе идемпотентных глаголов серверу.
gbjbaanb
Не все REST-запросы являются идемпотентными. Например, многократная выдача POST приведет к появлению большого количества новых ресурсов.
Гари Роу