Якович (1207873), страница 4
Текст из файла (страница 4)
302: Временно перемещен (Moved Temporarily).
Требуемый ресурс на некоторое время перемещен на другой URI. В силу того, что перемещение лишь временное, клиенту не следует изменять URI на который он обращается, чтобы получить этот ресурс.
В случае, когда новый URI является расположением ресурса, а не самим ресурсом, то в ответе нужно указать в поле Location новый URL. Когда код 302 получен в ответе к запросу, не являющимся GET или HEAD, приложение клиента должно предложить выбор действий, не производя автоматического перенаправления без ведома клиента.
4xx. Коды ошибок на стороне клиента:
Содержат информацию на случай, если клиент допустил ошибку в запросе, параметрах запроса или URI. В ответе желательно разместить сообщение, объясняющее проблему.
В случае ошибки, когда клиент посылает данные серверу, а сервер использует TCP, серверу сперва следует получить подтверждение, что клиент получил пакеты, содержащие ответ на свой запрос, перед тем как сервер закроет соединение с клиентом.
400: Испорченный Запрос (Bad Request)
Происходит, когда сервер не может интерпретировать запрос. Клиенту следует повторить запрос, исключив модификации и не входящие в спецификацию протокола поля.
401: Несанкционированное (Unauthorized)
Используется, когда необходима авторизация от пользователя на уровне HTTP. Когда ресурс запрашивается, в ответе указывается поле www-authenticate, которое сообщает клиентскому приложению, что необходимо авторизоваться (например, в браузерах отображается форма авторизации с полями «Пользователь» и «Пароль»). Если в запросе присутствует поле Authorization, то сервер проверят подлинность введенных данных и в случае неудачи отправляет ответ с кодом 401.
403: Запрещено (Forbidden)
Сообщает о том, что сервер отказывается выполнить запрос по какой-либо причине, которую сервер не должен указывать. Это может быть внутренний закрытый механизм, доступный по определенным параметрам, не зависящий от авторизации стандартными методами HTTP.
404: Ресурс не найден (Not Found)
В результате запроса на определенный URI сервер не нашёл требуемый ресурс. Не содержит описания проблемы. В случае, когда клиенту не следует знать о том, что данный ресурс недоступен, сервер может вернуть код 403 (Запрещено), код 410 (Удален). Такой ход можно использовать, если нет информации о том, куда пропал ресурс, будет ли он восстановлен или появится перенаправление на корректный URI.
413: Объект в запросе слишком большой (Request Entity Too Large)
Сущность, передаваемая в запросе превосходит объем данных, которые может обработать сервер за один запрос. Как правило, данный параметр указывается на стороне сервера.
414: Запрашиваемый URI слишком длинный (Request-URI Too Long).
Сервер не может обработать URI заданной длины. Такое состояние очень редкое, поскольку, в соответствии со спецификацией HTTP-протокола, всякий сервер должен быть в состоянии обрабатывать URI сколь угодной длины.
Подобное может произойти если клиент неправильно преобразует POST запрос к GET запросу с данными имеющими большую длину. Также это возможно, если клиент попал в «черную дыру» перенаправления (перенаправленный URL префикс указывает на свой суффикс). Такое возможно, если на сервер производится атака на имеющиеся уязвимости в серверах, которые используют буфера фиксированной длины для чтения.
5xx. Коды ошибок на стороне сервера:
Коды, начинающиеся на «5», описывают ситуации, когда сервер знает о существовании допущенной ошибки или не может обработать запрос. Серверу всегда следует в ответе размещать сообщение содержащее объяснение ошибки и информацию, характеризующую ошибку.
500: Внутренняя ошибка сервера (Internal Server Error)
Сервер по некоторым причинам не в состоянии выполнить запрос клиента.
501: Не реализовано (Not Implemented)
Сервер не поддерживает функциональные возможности, требуемые для выполнения запроса. Этот ответ соответствует состоянию, когда сервер не распознает метод запроса и не способен обеспечить его для любого ресурса.
502: Ошибка шлюза (Bad Gateway)
Сервер, действуя в качестве шлюза или прокси-сервера, получил недопустимый ответ от следующего сервера в цепочке запросов, к которому обратился при попытке выполнить запрос.
503: Service Unavailable (сервис недоступен)
Серверу не удаётся обработать запрос поскольку он может быть перегружен, или на техническом обслуживании, или просто сломаться. Если сервер заранее знает, как долго он не будет работоспособен, то можно указать длительность в ответе в поле заголовка Retry-After.
Ответ содержащий код 503 необязательно говорит о том, что серверу следует воспользоваться им, когда он перегружен. Часть серверов может просто прервать соеденение.
504: Gateway Timeout (истекло время ожидания от шлюза)
Сервер, действуя в качестве шлюза или прокси-сервера, не получил своевременного ответа от следующего сервера в цепочке запросов, к которому обратился при попытке выполнить запрос.
1.10 Веб-сервисы (веб-службы)
Под веб-сервисом понимается идентифицируемая URI система со стандартизированными интерфейсами (API). В первую очередь веб-сервисы характеризуются архитектурой SOA (сервис-ориентированная архитектура). Их основная задача обработка запросов и предоставление ответов на предоставленный запрос, быть источниками данных.
Веб-сервисы часто используются для передачи данных между независимыми приложениями, которые могут физически находиться в разных местах, иметь разные URL-адреса, работать на разных платформах (операционных системах) и написаны на разных языках программирования.
Они могут взаимодействовать как друг с другом, так и со сторонними приложениями с помощью «сообщений» (например, HTTP-запросов). Веб-сервис представляет собой модульную единицу в сервис-ориентированной архитектуре приложений.
В обиходе веб-сервисами называют услуги, оказываемые в Интернете, такие как онлайн-калькуляторы, онлайн-хранилища и другие. В целом термин требует уточнения, идёт ли речь о поиске, веб-почте, хранилище документов, файлов и другие. Множеством веб-сервисов можно пользоваться независимо от компьютера, браузера или места доступа в Интернет.
Веб-сервисы основаны на базе открытых стандартов и протоколов. Использование интернет-протокола обеспечивает HTTP-взаимодействие программных систем через межсетевой экран. С другой стороны, веб-службы не привязаны только к HTTP — могут использоваться и другие протоколы.
1.11 REST-сервисы
REST является на сегодняшний день самым популярным архитектурным стилем разработки веб-сервисов. REST не является протоколом и не может похвастаться новизной. Он является архитектурным стилем, который был предложен в 2000-ые годы Роем Филдингом в его диссертации «Architectural Styles and the Design of Network-based Software Architectures».
До этого REST был использован во множестве проектов в рамках IETF и W3C. В диссертации Роя Филдинга нет таких терминов как «веб-сервис» или «SOA» (сервис-ориентированная архитектура), его REST архитектура была предложена для правильного конструирования распределенных гипермедиа систем, иными словами, что сегодня называется World Wide Web, и полного использования возможностей HTTP-протокола. Также Рой Филдинг является архитектором HTTP 1.1, соавтором интернет стандартов для HTTP и URI.
REST обладает определенными принципами для построения архитектуры. Если архитектура соответствует всем принципам, то такой веб-сервис называется RESTful (или RESTful-сервис).
Независимость от состояния (Statelessness):
Первый принцип – независимость от состояния. Сервер не должен отслеживать, хранить и использовать текущую информацию о клиенте. Это также означает, что данные, которые отдаёт API при вызове, не должны зависеть от запросов и вызовов, происходивших ранее. Всё должно происходить в рамках одного запроса. В случае, если необходимы какие-либо параметры, характеризующие состояние, для этого создаются определенные фильтры и данные параметры передаются в запросе при вызове API.
Кэшируемая и многоуровневая архитектура:
Второй принцип заключается в предоставлении клиенту информации о том, что ответ сервера может быть кэширован на определенный период времени и использоваться повторно без новых запросов к серверу. Этим клиентом может быть, как сам клиентский агент, посылающий запросы, так и промежуточный прокси сервер.
Клиент – серверная архитектура:
Сервер должен скрывать от клиента как можно больше деталей своей реализации. Клиенту не нужно знать о том, какая СУБД используется на сервере или сколько серверов в данный момент обрабатывают запросы и прочие технические нюансы.
Единый, универсальный интерфейс:
Универсальный интерфейс взаимодействия между компонентами системы. Для создания универсального интерфейса вводятся следующие условные ограничения:
– Идентификация ресурсов: в REST ресурсом является все то, чему можно дать имя. Например, пользователь, HTML документ, изображение, зарегистрированный пользователь, текущая погода и т.д. Каждый ресурс должен быть идентифицирован посредством URI, который не меняется при изменении состояния этого ресурса.
– Управление ресурсами через представление: представление в REST используется для выполнения действий над ресурсами. Представление ресурса – это текущее или желаемое его состояние. Например, если ресурсом является пользователь, то представлением может являться XML или JSON описание этого пользователя.
– Описание самих себя: под этим подразумевается, что запрос и ответ могут и должны содержать в себе необходимую и достаточную информацию для их обработки.
HATEOAS (hypermedia as the engine of application state, ресурсы сами описывают свои возможности и взаимосвязи):
Данный пункт означает, что гипертекст должен быть использован для навигации по API, будь то перекрестные и связанные ссылки, указания на главы в документации и т.д.
Разделение системы на слои:
В REST допускается разделение системы на иерархически связанные слои с условием, что каждый компонент одного слоя может иметь доступ к компонентам только следующего слоя. Например, если вы вызываете службу «PayPal», а он, в свою очередь, вызывает службу «Visa», но вы о вызове службы «Visa» ничего не должны узнать.
Код по требованию:
Допускается возможность загрузки кода клиентами для выполнения на клиентской машине, например, «JavaScript», «Java Applets».
Таким образом, если система удовлетворяет всем описанным пунктам, то можно утверждать, что она устроена по REST, и является RESTful.
REST архитектура оправдала себя в течении последних 17-и лет на практике в веб-разработке. Поскольку веб-сервисы являются частью интернета, многими компаниями/разработчиками/исследователями было решено и в случае веб-сервисов применить архитектуру REST, что позволит улучшить масштабируемость компонентов, обеспечить безопасность, независимое развертывание и т.д.
По сей день REST неизбежно захватывает веб-пространство, создается всё больше веб-сервисов, основанных на REST принципах, создаются фронт-энд фреймворки, заточенные под работу с веб-сервисами (например, AngularJS, очень гибкий, мощный и популярный). В ближайшем будущем распространение REST-сервисов будет расти и дальше.
Значимость REST нельзя недооценивать, благодаря ей во всю мощь используется HTTP-протокол, грамотно применяются его методы и возможности в соответствии с изначальной задумкой, он лаконичен, прост, удобен, масштабируем и способен работать быстро настолько, насколько это возможно. Учитывая, как быстро развивается интернет, REST будет расти с той же скоростью.
1.12 Построение маршрутов URI для REST
Эта часть является наиболее важной при проектировке REST-сервиса. Главной идеей является выделение отдельных URL для каждой сущности. К примеру, у нас имеется две таблицы: Master(хозяин) и Dog (собака). Эти таблицы связаны по ключу: каждый хозяин может иметь одну и более собак.
При проектировании будут выделены следующие URI:
– GET: */api/masters – получить список хозяев;
– GET: */api/masters/{id} – получить информацию о хозяине по его id;
– GET: */api/masters/{id}/dogs – получить информацию о собаке конкретного хозяина;
– GET: */api/dogs – получить список собак;
– GET: */api/dogs/{id} – получить информацию о собаке по её id;
– GET: */api/dogs/{id}/master – получить информацию о хозяине собаки,
где «*» – URI http://example.com.
При такой проектировке маршрутов интуитивно понятно, какие данные мы получим при запросе.
1.13 CRUD в REST
Поскольку REST тесно связан с HTTP-протоколом и призывает использовать все его возможности, все CRUD-операции (создать, прочитать, дополнить/обновить/изменить, удалить) выполняются с помощью стандартных HTTP-методов, описанных в разделе HTTP-методы.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
