Что такое протокол REST и чем он отличается от протокола HTTP?
В чем разница между протоколами REST и HTTP?
Ответ 1
REST - это подход, который использует протокол HTTP и не является альтернативой ему.
Данные однозначно ссылаются по URL-адресу и могут быть использованы при использовании HTTP-операций (GET, PUT, POST, DELETE и т.д.). Для сообщения/ответа поддерживается большое количество типов mime, но наиболее распространены XML и JSON.
Например, чтобы прочитать данные о клиенте, вы можете использовать операцию HTTP get с URL http://www.example.com/customers/1. Если вы хотите удалить этого клиента, просто используйте операцию удаления HTTP с тем же URL-адресом.
В приведенном ниже коде Java показано, как сделать вызов REST по протоколу HTTP:
String uri =
"http://www.example.com/customers/1";
URL url = new URL(uri);
HttpURLConnection connection =
(HttpURLConnection) url.openConnection();
connection.setRequestMethod("GET");
connection.setRequestProperty("Accept", "application/xml");
JAXBContext jc = JAXBContext.newInstance(Customer.class);
InputStream xml = connection.getInputStream();
Customer customer =
(Customer) jc.createUnmarshaller().unmarshal(xml);
connection.disconnect();
Для примера Java (JAX-RS) см.
Ответ 2
REST - это стиль дизайна для протоколов, он был разработан Роем Филдингом в его докторской диссертации и формализовал подход, стоящий за HTTP/1.0, и нашел, что с ним хорошо сработало, а затем используя это более структурированное понимание этого, чтобы повлиять на дизайн HTTP/1.1. Итак, хотя это было по-фактам во многих отношениях, REST - это стиль дизайна HTTP.
Фигурирование диссертации можно найти на http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm и очень полезно читать, а также очень читаемо. Диссертации доктора могут быть довольно трудными, но этот чудесно хорошо описан и очень читаем для тех из нас, которые не имеют сопоставимого уровня Информатики. Это помогает, что REST сам по себе довольно прост; это одна из тех вещей, которые очевидны после того, как кто-то еще придумал это. (И в этом случае инкапсулирует многие вещи, которые старые веб-разработчики усердно усвоили в одном простом стиле, что сделало его важным для многих "ха!" ).
Другие протоколы на уровне приложений, а также HTTP также могут использовать REST, но HTTP - классический пример.
Поскольку HTTP использует REST, все использование HTTP использует систему REST. Описание веб-приложения или услуги как RESTful или non-RESTful относится к тому, использует ли он REST или работает против него.
Классический пример системы RESTful - это "простой" веб-сайт без куки файлов (файлы cookie не всегда соответствуют REST, но они могут быть): состояние клиента изменяется пользователем, щелкнув ссылку, которая загружает другую страницу, или делая запросы формы GET, которые приносят результаты. Запросы формы POST могут изменять состояние сервера и клиента (сервер делает что-то на основе POST, а затем отправляет гипертекстовый документ, описывающий новое состояние). URI описывают ресурсы, но описываемый объект (документ) может отличаться в зависимости от типа или языка контента, предпочитаемого пользователем. Наконец, браузеру удалось обновить саму страницу через PUT и DELETE, хотя это никогда не было очень распространенным явлением, и если теперь что-то не так.
Классический пример не-RESTful-системы с использованием HTTP - это то, что относится к HTTP, как к транспортному протоколу, и каждый запрос отправляет POST данных в тот же URI, который затем обрабатывается в RPC-подобном возможно, с самим соединением, имеющим общее состояние.
RESTful, читаемый компьютером (т.е. не веб-сайт в браузере, но что-то, что используется программно), получит информацию о соответствующих ресурсах с помощью GETting URI, который затем вернет документ (например, в XML, но не обязательно), который описывают состояние ресурса, включая URI для связанных ресурсов (поэтому гипермедиа), изменяют свое состояние через объекты PUTting, описывающие новое состояние, или УДАЛИТЬ их, и выполняют другие действия, выполняемые POSTing.
Ключевые преимущества:
Масштабируемость. Отсутствие общего состояния делает гораздо более масштабируемую систему (продемонстрировала мне массово, когда я удалил все использование состояния сеанса с сильно пострадавшего веб-сайта, в то время как я ожидал, что он даст немного дополнительную производительность, даже давний антисемитский адвокат, как и я, был потрясен огромным выигрышем от удаления того, что было довольно тонким использованием сессий, даже не потому, что я их удалял!)
Простота: Есть несколько разных способов, в которых REST проще, чем больше RPC-подобных моделей, в частности, есть только несколько "глаголов", которые когда-либо возможны, и каждый тип ресурса может быть обоснован в разумной изоляции другим.
Легкие сущности. Более похожие на RPC модели, как правило, имеют множество данных в сущности, отправленных в обоих направлениях, чтобы отразить RPC-подобную модель. Это не нужно. В самом деле, иногда простой текстовый документ - это все, что действительно необходимо в данном случае, и в этом случае с REST, что все, что нам нужно будет отправлять (хотя это будет только случай "конечный результат", текст не связан с соответствующими ресурсами). Другим классическим примером является запрос на получение файла изображения, RPC-подобные модели обычно должны переносить его в другом формате и, возможно, кодировать его каким-либо образом, чтобы он мог находиться в родительском формате (например, если RPC-подобная модель использует XML, образ должен быть base-64'd или подобным, чтобы соответствовать действующему XML). Модель RESTful просто передаст файл так же, как и браузеру.
Результаты, читаемые человеком: не обязательно так, но часто бывает легко создать веб-сервис RESTful, где результаты относительно легко читаются, что помогает отлаживать и развивать без конца. Я даже построил один, где XSLT означает, что все это может быть использовано людьми как (относительно грубый) веб-сайт, хотя это не было прежде всего для использования человеком (по существу, XSLT служил клиентом для представления его пользователей, это было даже не в спецификации, просто сделано, чтобы сделать мою собственную разработку проще!).
Связывание Looser между сервером и клиентом: ведет к более быстрой разработке или перемещению в том, как система размещается. Действительно, если вы придерживаетесь гипертекстовой модели, вы можете изменить всю структуру, в том числе переходить с одного хоста на несколько хостов для разных служб, не изменяя код клиента вообще.
Кэширование. Для операций GET, когда клиент получает информацию о состоянии ресурса, стандартные механизмы кэширования HTTP позволяют как для операторов, так и ресурс не будет значимо изменяться до определенной даты (не нужно запрашивать в все до тех пор) или что он не изменился со времени последнего запроса (отправьте пару сотен байт заголовков, говорящих это, а не несколько килобайт данных). Улучшение производительности может быть огромным (достаточно большим, чтобы перенести выполнение чего-либо с того момента, когда нецелесообразно использовать его до такой степени, что производительность в некоторых случаях больше не является проблемой).
Доступность наборов инструментов: поскольку он работает на относительно простом уровне, если у вас есть веб-сервер, вы можете создать системный сервер RESTful, и если у вас есть какой-либо HTTP-клиентский API (XHR в браузере javascript, HttpWebRequest в .NET и т.д. ) вы можете создать системный клиент RESTful.
Resiliance: В частности, отсутствие общего состояния означает, что клиент может умереть и вернуться к использованию без знания сервера, и даже сервер может умереть и вернуться к использованию без знания клиента. Очевидно, что связь в течение этого периода не удастся, но как только сервер вернется в Интернет, все может просто продолжаться так, как было. Это также действительно упрощает использование веб-ферм для избыточности и производительности - каждый сервер действует как единственный сервер, и не имеет значения, что на самом деле он имеет дело только с частью запросов от данного клиента.
Ответ 3
REST не является протоколом, он представляет собой обобщенную архитектуру для описания безгражданности, кэширования клиент-серверной платформы распределенных медиа. Архитектура REST может быть реализована с использованием нескольких различных протоколов связи, хотя HTTP является наиболее распространенным.
Ответ 4
REST не является протоколом, это способ разоблачения вашего приложения, в основном выполняемого через HTTP.
например, вы хотите открыть api вашего приложения, которое делает getClientById
вместо создания URL
yourapi.com/getClientById?id=4
вы можете сделать
yourapi.com/clients/id/4
поскольку вы используете метод GET, это означает, что вы хотите получать данные
Вы используете преимущества над методами HTTP: GET/DELETE/PUT
yourapi.com/clients/id/4 также может обрабатывать удаление, если вы отправляете метод удаления, а не GET, что означает, что вы хотите удалить запись
Ответ 5
Все ответы хороши.
Я тем самым добавляю подробное описание REST и как он использует HTTP.
REST = Передача репрезентативного состояния
REST - это набор правил, которые после этого позволяют создавать распределенное приложение с определенным набором желаемых ограничений.
Он не имеет состояния, что означает, что в идеале между клиентом и сервером не должно поддерживаться соединение.
Клиент должен передать свой контекст серверу, а затем сервер может сохранить этот контекст для обработки запроса клиента. Например, сеанс, поддерживаемый сервером, идентифицируется идентификатором сеанса, переданным клиентом.
Преимущества безгражданства:
- Веб-службы могут обрабатывать каждый вызов метода отдельно.
- Веб-службы не должны поддерживать предыдущее взаимодействие с клиентом.
- Это, в свою очередь, упрощает разработку приложений.
- HTTP сам по себе является протоколом без учета состояния, в отличие от TCP, и поэтому RESTful Web Services работает с HTTP-протоколами.
Недостатки безгражданства:
- В каждый запрос необходимо добавить один дополнительный уровень в виде заголовка для сохранения состояния клиента.
- Для обеспечения безопасности нам может понадобиться добавить информацию заголовка к каждому запросу.
Методы HTTP, поддерживаемые REST:
GET: /string/someotherstring:
Это idempotent (означает, что множественные вызовы должны возвращать одинаковые результаты каждый раз) и в идеале должны возвращать одинаковые результаты при каждом вызове
PUT:
То же, что и GET. Идемпотент и используется для обновления ресурсов.
POST: должен содержать URL-адрес и тело
Используется для создания ресурсов. Несколько вызовов должны идеально возвращать разные результаты и создавать несколько продуктов.
DELETE:
Используется для удаления ресурсов на сервере.
ГОЛОВА:
Метод HEAD идентичен GET, за исключением того, что сервер НЕ ДОЛЖЕН возвращать тело сообщения в ответ. Мета-информация, содержащаяся в заголовках HTTP в ответ на запрос HEAD, ДОЛЖНА быть идентичной информации, отправленной в ответ на запрос GET.
ОПЦИИ:
Этот метод позволяет клиенту определять параметры и/или требования, связанные с ресурсом, или возможности сервера, не подразумевая действия ресурса или инициирования поиска ресурсов.
HTTP-ответы
Перейдите сюда для всех ответов.
Вот несколько важных из них:
200 - ОК
3XX - Дополнительная информация, необходимая для перенаправления клиента и URL-адреса
400 - Плохой запрос
401 - Несанкционированный доступ к
403 - Запрещенный
Запрос был действительным, но сервер отказывается от действия. Пользователь может не иметь необходимых разрешений для ресурса или может потребоваться какая-либо учетная запись.
404 - Не найдено
Запрошенный ресурс не может быть найден, но может быть доступен в будущем. Возможны последующие запросы клиента.
405 - Метод не разрешен Метод запроса не поддерживается для запрашиваемого ресурса; например, запрос GET в форме, для которой данные должны быть представлены через POST, или запрос PUT для ресурса, доступного только для чтения.
404 - Запрос не найдено
500 - Внутренняя ошибка сервера
502 - Ошибка с плохим шлюзом