Архитектура REST

REST (Representational state transfer) – это стиль архитектуры программного обеспечения для распределенных систем, таких как World Wide Web, который, как правило, используется для построения веб-служб. Термин REST был введен в 2000 году Роем Филдингом, одним из авторов HTTP-протокола. Системы, поддерживающие REST, называются RESTful-системами.
В общем случае REST является очень простым интерфейсом управления информацией без использования каких-то дополнительных внутренних прослоек. Каждая единица информации однозначно определяется глобальным идентификатором, таким как URL. Каждая URL в свою очередь имеет строго заданный формат.
А теперь тоже самое более наглядно:
Отсутствие дополнительных внутренних прослоек означает передачу данных в том же виде, что и сами данные. Т.е. мы не заворачиваем данные в XML, как это делает SOAP и XML-RPC, не используем AMF, как это делает Flash и т.д. Просто отдаем сами данные.
Каждая единица информации однозначно определяется URL – это значит, что URL по сути является первичным ключом для единицы данных. Т.е. например третья книга с книжной полки будет иметь вид /book/3, а 35 страница в этой книге — /book/3/page/35. Отсюда и получается строго заданный формат. Причем совершенно не имеет значения, в каком формате находятся данные по адресу /book/3/page/35 – это может быть и HTML, и отсканированная копия в виде jpeg-файла, и документ Microsoft Word.
Как происходит управление информацией сервиса – это целиком и полностью основывается на протоколе передачи данных. Наиболее распространенный протокол конечно же HTTP. Так вот, для HTTP действие над данными задается с помощью методов: GET (получить), PUT (добавить, заменить), POST (добавить, изменить, удалить), DELETE (удалить). Таким образом, действия CRUD (Create-Read-Updtae-Delete) могут выполняться как со всеми 4-мя методами, так и только с помощью GET и POST.
Вот как это будет выглядеть на примере:
GET /book/ — получить список всех книг
GET /book/3/ — получить книгу номер 3
PUT /book/ — добавить книгу (данные в теле запроса)
POST /book/3 – изменить книгу (данные в теле запроса)
DELETE /book/3 – удалить книгу
ВАЖНОЕ ДОПОЛНЕНИЕ: Существуют так называемые REST-Patterns, которые различаются связыванием HTTP-методов с тем, что они делают. В частности, разные паттерны по-разному рассматривают POST и PUT. Однако, PUT предназначен для создания, реплейса или апдейта, для POST это не определено (The POST operation is very generic and no specific meaning can be attached to it). Поэтому мой пример будет правильным и в таком виде, и в виде если поменять местами POST и PUT.
Вообще, POST может использоваться одновременно для всех действий изменения:
POST /book/ – добавить книгу (данные в теле запроса)
POST /book/3 – изменить книгу (данные в теле запроса)
POST /book/3 – удалить книгу (тело запроса пустое)
Это позволяет иногда обходить неприятные моменты, связанные с неприятием PUT и DELETE.

69. П онятие сервлета. Интерфейсы для работы с сервлетами.

Сервлеты представляют собой фрагменты исходного кода Java™, которые добавляют новые функциональные возможности на Web-сервер так же как апплеты добавляют функциональные возможности в броузер. Сервлеты поддерживают модель вычислений запрос-ответ, которая широко используется Web-серверами. Согласно этой модели, клиент посылает сообщение с запросом на сервер, а сервер, в свою очередь, отвечает клиенту, посылая ответное сообщение. Запросы могут приходить в форме HTTP, URL, FTP, URL или по специальному протоколу.

Схема работы сервлеты:

1. Пользователь вводит URL в браузере. Конфигурационный файл вашего Web-сервера указывает, что этот URL предназначен для сервлета, управляемого контейнером сервлетов (Tomacat) сервере.

2. Если экземпляр сервлета еще не был создан (существует только один экземпляр сервлета для приложения), контейнер загружает класс и создает экземпляр объекта.

3. Контейнер вызывает метод init() сервлета.

4. Контейнер вызывает метод service() сервлета и передает HttpServletRequest и HttpServletResponse.

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

6. При необходимости, когда сервлет выполнил полезную работу, контейнер вызывает метод destroy() сервлета для его финализации.

Java Servlet API включает несколько интерфейсов Java и полностью определяет связь между сервером и сервлетами. Servlet API определяется как расширение стандартного JDK. Расширения JDK пакетируются в библиотеке javax – корневой в дереве библиотек расширений Java. Java Servlet API содержит следующие пакеты: javax.servlet и javax.servlet.http

Сервлеты выполняются на платформе Web-сервера как часть того же процесса, что и сам Web-сервер. Web-сервер отвечает за инициализацию, вызов и уничтожение каждого экземпляра сервлета. Web-сервер взаимодействует с сервлетом через простой интерфейс: javax.servlet.Servlet. Этот интерфейс состоит из трех главных методов:

• init() - вызывается при первой загрузке. Гарантируется, что данный метод завершится прежде чем будет вызван любой другой метод. Вызывается только один раз; он не будет вызываться до тех пор, пока сервлет не будет выгружен и затем загружен сервером снова..

• service() – ключевой метод. Вызывается при каждом запросе клиента. Читает запрос и формирует ответ при помощи 2ух аргументов: 1) Объект ServletRequest содержит данные от клиента. Данные состоят из пар имя/значение и InputStream. 2) Объект ServletResponse содержит ответ сервлета клиенту. Во время подготовки ответа прежде всего вызывается метод setContentType() для установки типа MIME ответа.

• destroy() - вызывается для того, чтобы возможность освободить все ресурсы перед выгрузкой сервлета.