Тысячи лет назад, когда мы впервые начали создавать веб-страницы, все было очень просто. Вы поместили бы некоторый текст на страницу, возможно даже изображение, и это было в значительной степени это. Но сегодня это совсем другая игра с мячом. Вместо статических страниц есть динамические приложения, от которых мы стали зависеть. И так, как эти приложения предназначены для общения, становится очень важным. В этой серии я познакомлю вас со стилем архитектуры REST. В этой статье я помогу вам понять, что это такое, а позже я покажу вам, как это можно реализовать в среде PHP.
Что такое ОТДЫХ?
REST — это набор принципов, которые определяют, как сервер и клиент могут общаться друг с другом (и внешними ресурсами) простым, понятным и надежным способом. Хотя вы часто будете видеть слова «REST» и «архитектура» вместе, REST не является специфической архитектурой. Мне нравятся слова, использованные доктором М. Элкстейном в « Learn REST: Учебное пособие», когда он назвал это «архитектурным стилем». REST содержит определенные рекомендации о том, как вещи должны быть построены, но не настаивает на том, чтобы вещи строились определенным образом с использованием определенного здания. блоки.
Во многих ссылках вы увидите, что REST и SOAP упоминаются как конкуренты. Это неправда. SOAP — это протокол, а не стиль архитектуры. То, с чем можно сравнить REST — это SOA и RPC. Все три являются примерами стилей веб-сервисов, каждый из которых имеет свою концептуальную направленность. RPC сосредоточен на операциях, SOA на сообщениях и REST на ресурсах.
Идеи, лежащие в основе REST, были уже давно, впервые появившись в докторской диссертации Роя Филдинга, одного из разработчиков протокола HTTP. В самом деле, влияние REST на HTTP и, следовательно, на сам Интернет, хорошо видно. Но REST не является стандартом или протоколом; нет документов W3C, в которых указано, что это должно быть, и нет номеров версий на сегодняшний день. Если вы делаете REST, вы, безусловно, в конечном итоге будете действовать определенным образом, но это не то же самое, что говорить, что это стандарт.
REST означает REpresentational State Transfer , и хотя для меня это ничего не значило в первый раз, когда я увидел его, у Филдинга были очень четкие представления о его значении.
- Репрезентация относится к тому факту, что когда вы получаете доступ к чему-либо через Интернет, вам возвращается представление объекта, а не сам объект. Если вы выйдете и получите список адресов, вы можете получить поток данных XML, а не реальную базу данных, в которой хранятся адреса.
- Состояние означает, что на сервере не должно быть состояния сеанса. Каждый запрос от клиента должен содержать всю необходимую информацию, чтобы сервер мог понять контекст запроса без ссылки на предыдущую транзакцию. Все состояние поддерживается клиентом.
- И передача относится к тому, как данные передаются по сети между клиентами и серверами.
Принципы ОТДЫХА
Итак, если REST — это набор принципов, каковы эти принципы?
Все идентифицировать как URI — Все в REST является представлением некоторого ресурса, который может быть идентифицирован уникальным URI (унифицированным идентификатором ресурса). Так устроен сам веб, и он обеспечивает простоту, которая недоступна, если ресурсам присваивается множество различных номенклатур.
Гипермедиа как движок состояния приложения. Одной из красот Интернета является возможность ссылки с одной страницы на другую, так почему бы не использовать ее в качестве основы для передачи всех состояний? Клиенты переходят через веб-приложение только через действия внутри ресурса, такие как гиперссылки.
Запросы без гражданства — в основе REST лежит идея безгражданства. То есть каждый запрос, обрабатываемый сервером, может быть выполнен, ничего не зная ни о каком предыдущем запросе. Или, другими словами, клиент предоставляет в запросе всю необходимую информацию, необходимую серверу для ее выполнения.
Использование стандартного протокола — в REST нет ничего, что требовало бы использования HTTP. И все же, в большинстве случаев, когда вы видите систему REST, она основана на HTTP. Причина этого заключается в том, что HTTP использует четыре основные операции ( GET , PUT , POST и DELETE ) для выполнения всех операций, а REST тяготеет к небольшому стандартизированному набору операций.
В целом, REST поощряет простоту и стандартизацию, пытаясь позволить уже существующим функциям протокола выполнить большую часть тяжелой работы и избавляя от необходимости заново изобретать эти функции с помощью написанных программистом операций. Хотя большая часть разработки веб-приложений, проводимой сегодня, использует подход RPC или SOA, растет интерес к использованию более простого и в то же время надежного стиля, который поддерживает REST.
PUT vs. POST
Как я уже отмечал выше, REST не является истинной архитектурой и не заставляет вас использовать определенные инструменты или протоколы. Но большинство реализаций используют HTTP, прежде всего из-за его простоты. В каждом протоколе определены операции, которые выполняют работу CRUD (создание, извлечение, обновление и удаление), необходимую для данных. HTTP использует четыре основные операции GET , PUT , POST и DELETE для выполнения своей работы CRUD.
Как и следовало ожидать, GET извлекает данные для вас, а DELETE удаляет данные. И это подводит нас к PUT и POST . Обсуждение любого из них, но особенно POST немного похоже на обсуждение религии или политики; Вы обязаны кого-то расстроить. Но здесь идет …
Некоторые люди склонны связывать PUT с созданием, а POST с обновлением. Но я, честно говоря, считаю, что это слишком упрощение, вроде того, чтобы сказать, что Темная сторона Силы — это то, что вы испытываете в день, когда вы немного ворчливы. В действительности между этими двумя методами существуют значительные различия.
Во-первых, давайте начнем с термина «идемпотент». Это не следует путать с одноименным, очень серьезным заболеванием для мужчин, которое можно лечить только с помощью ряда лекарств, ни один из которых не является уличным законом за пределами Восточной Европы. Идемпотент означает, что если вы примените операцию несколько раз, вы получите тот же результат, как если бы вы только что применили ее один раз. Какая разница? Это разница между покупкой одной подлинной фигурки Долли Партон или пяти, если вы совершаете покупки в Интернете и нажимаете клавишу Enter несколько раз слишком часто. Оказывается, что GET , PUT и DELETE все идемпотентны. POST нет.
Единственный способ выполнить одну и ту же операцию несколько раз и не допустить, чтобы она все испортила, — это передать все данные, связанные с ресурсом, при запросе операции. Следовательно, это то, что делает PUT . Сервер получает все доступные данные и полностью перезаписывает ресурс. Неважно, ресурс уже там или нет; Вы полностью заменяете его, поэтому создание и обновление обрабатываются одинаково.
POST , с другой стороны, не является идемпотентом. Если вы сделаете это несколько раз, произойдет несколько вещей. Например, если вы создаете новую учетную запись пользователя и используете POST , вы будете создавать новую учетную запись при каждом нажатии Enter. POST запросов POST требуются только некоторые, но не все данные, связанные с ресурсом. На самом деле очень хорошо, если отправляемые вами данные представляют собой дополнение к уже существующему ресурсу, например, добавление комментария к сообщению в блоге или обновление заявки на устранение неисправности. Ты следишь за мной, гладко?
Во-вторых, поскольку REST — это стиль архитектуры, ориентированный на ресурсы (в отличие от сообщений, ориентированных на SOA, и операций, ориентированных на RPC), давайте рассмотрим это с точки зрения того, что происходит с ресурсом. PUT , идемпотентная операция, влияет на URI, указанный в запросе. То есть он обновляет ресурс по URI, предоставленному клиентом. POST влияет на URI, созданный и названный сервером. Ресурс обновляется данными, передаваемыми от клиента, но ресурс является отдельным и отличным от имени URI, названного клиентом.
Хороший вопрос, который нужно задать, когда вы спорите с самим собой о PUT vs POST : кто должен называть URI, клиентскую сторону или сервер? Другой способ это указать: хотите ли вы сохранить контроль над URI или обработать его, чтобы сервер создавал связанные URI. Сообщение в блоге может быть создано с помощью POST example.com/blog . Сервер создаст запись с идентификатором 42, которая затем будет доступна как example.com/blog/42 . В качестве альтернативы, сообщение в блоге может быть создано с помощью PUT example.com/blog/42 если ресурс еще не существует (в этом случае он будет заменен). Именование ресурса example.com/blog/42 оставлено на POST сервера с POST и до клиента с PUT .
Резюме
REST — это не установленный способ действий, это состояние ума, основанное на паре простых принципов: относиться ко всему как к ресурсу, идентифицированному URI, использовать гиперссылки для перехода от одного ресурса к другому, обрабатывать все как состояние без состояния и использовать стандартный протокол с общими операциями. Преимущество REST по сравнению с SOA или RPC заключается в простоте и скорости (поскольку затраты на сборку и обработку данных снижаются, при этом вы можете создать надежную и надежную систему. Большинство приложений REST используют HTTP (из-за его простоты), поэтому важно понимать разницу между методами PUT и POST .
В следующей главе этой саги наш герой покажет вам, как PHP вписывается во все это. Как можно использовать PHP с REST и, в частности, как он взаимодействует с HTTP. Я не знаю о вас, но я в восторге! Я не могу дождаться, чтобы узнать больше об этой захватывающей технике.
Изображение через littlesam / Shutterstock