Нужен HTTP-сервер? Не вопрос, используем java.net.ServerSocket, будем
принимать входящие соединения, затем socket.getInputStream(), прочитаем
данные и...
Стоп! Эдак придётся байты в строку переводить, потом выделять метод, url, заголовки, тело - столько всего! Можно проще?
Можно! Spring MVC - наше всё :) Далее в посте - пример создания контроллера с удобным маппингом.
(ну, по справедливости, можно сделать проще и без spring'а, но я же ведь как раз про него пишу:) ).
Итак, примерная задача: требуется реализовать приём HTTP-запросов на открытие / закрытие сессии.
Итак, примерная задача: требуется реализовать приём HTTP-запросов на открытие / закрытие сессии.
Запросы отправляются на общий порт веб-приложения, на URI api/session/.
Запрос на открытие: open/ с параметрами "логин" (строковый) и "пароль"
(строковый), возвращается уникальный идентификатор открытой сессии
(число).
Запрос на закрытие: close/ с HTTP-заголовком X-SESSION со значением сессии, без ответа.
1) Внешние зависимости, которые нам потребуются (подтягиваются maven'ом)
<dependencies>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.0.1</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>3.2.5.RELEASE</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.6.4</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.6.4</version>
</dependency>
</dependencies>
При сборке будут подтянуты ещё некоторые компоненты spring framework (beans, context, core, web).
2) Содержимое web.xml
<?xml version="1.0" encoding="UTF-8"?>3) Cоответствующий сервлет spring-mvc-example-servlet.xml
<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
metadata-complete="true">
<servlet>
<servlet-name>spring-mvc-example</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>spring-mvc-example</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
</web-app>
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:mvc="http://www.springframework.org/schema/mvc"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd http://www.springframework.org/schema/mvc http://www.springframework.org/schema/mvc/spring-mvc.xsd">
<context:component-scan base-package="by.father.spring.*"/>
<context:annotation-config/>
<mvc:annotation-driven/>
</beans>
Вместо явного создания бинов в xml-конфиге мы просто указываем, что будем использовать аннотации.
Так, с xml закончили. Теперь перейдём непосредственно к коду.
4) Контроллер
Напомню, что контроллер - это класс, задачей которого является
непосредственная обработка запросов клиента и возвращение результатов.
При этом тайное желание любого контроллера - не превратиться в fat stupid ugly controller, т.е. не описывать логику обработки данных, но вызывать сервисные
методы в нужном порядке и возвращать результаты клиенту.
Сам бин класса-контроллера может быть определён явно, используя
стандартное определение spring beans в файле конфигурации. Также
@Controller позволяет автоопределение (autodetection) в соответствии с
общей поддержкой фреймворком обнаружения компонентов классов и
автоматической регистрацией бинов для них (именно поэтому в конфигурации
был context:component-scan).
package by.father.spring.mvc;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.*;
@Controller
@RequestMapping(value = "/api/session/", method = {RequestMethod.POST})
public class SessionController {
@Autowired
private SessionProcessor sessionProcessor;
@RequestMapping(value = "open/")
@ResponseBody
public Long open(@RequestParam String login, @RequestParam String pass) throws Exception {
return sessionProcessor.open(login, pass);
}
@RequestMapping(value = "close/")
@ResponseBody
public void close(@RequestHeader("X-SESSION") Long session) throws Exception {
sessionProcessor.close(session);
}
}
Аннотация @Controller "как бы намекает", что данный класс играет роль
контроллера. Всё, нет необходимости наследовать какой-нибудь базовый
класс контроллера и т.п.
Следующая использованная аннотация @RequestMapping предназначена для
того, чтобы задать методам контроллера адреса, по которым они будут
доступны на клиенте. Есть два основных применения этой аннотации:
- для всего класса контроллера - аннотация формирует своего рода "каталог" для методов контроллера
- для отдельного метода - детализирует сам метод.
В нашем примере метод open будет вызываться при обращении по
http://server:port/api/session/open, а метод close - при обращении по
http://server:port/api/session/close.
У этой аннотации @RequestMapping можно задать некоторые параметры:
- value - предназначен для указания адреса; его обычно применяют, если задаётся более, чем один параметр;
- method - определяет метод доступа. Варианты - RequestMethod.GET, RequestMethod.POST, RequestMethod.DELETE, RequestMethod.PUT и другие. Для класса можно указывать несколько методов method = {RequestMethod.GET, RequestMethod.POST};
- consumes - определяет тип содержимого тела запроса. Например, consumes="application/json" определяет, что Content-Type клиентского запроса должен быть "application/json". Можно задать отрицательное указание: consumes="!application/json" - тогда будет требоваться любой Content-Type, кроме указанного. Допускается указание нескольких значений: ("text/plain", "application/*);
- produces - этот параметр определяет формат возвращаемого методом значения. Если на клиенте в header'ах не указан заголовок Accept, то не имеет значение, что установлено в produces. Если же заголовок Accept установлен, то значение produces должно совпадать с ним для успешного возвращения результата клиенту. Параметр produces может также содержать перечисление значений;
- params позволяет отфильтровать запросы по наличию/отсутствию определённого параметра в запросе или по его значению. params="myParam=myValue", params="!myParam=myValue", params="myParam" и т.п.;
- headers позволяет отфильтровать запросы по наличию/отсутствию определённого заголовка в запросе или по его значению. headers="myHeader=myValue", headers="!myHeader=myValue", headers="myHeader", headers="!myHeader".
Далее в коде встречается аннотация @ResponseBody. Она указывается
непосредственно перед методом, если необходимо, чтобы результат работы
метода в контроллере был выведен непосредственно в тело ответа на
запрос, а не послужил адресом перехода и не был помещён как параметр в
модель.
- @RequestParam - получение параметра запроса; кроме значений, явно установленных в качестве параметров запроса, умеет распарсить и key-value строку, присланную в теле запроса.
- @PathVariable - предоставляет возможность получить какое-то значение прямо из адресной строки.
- @RequestBody - распознавание всего тела запроса как объекта (кстати, поскольку у запроса только одно тело, то нет возможности объявить более чем один параметр с этой аннотацией).
- @RequestHeader - получение непосредственно заголовки HTTP-запроса. В нашем примере именно в заголовке X-SESSION передаётся уникальный идентификатор сессии, и метод close как раз его и получает.
- @RequestPart - аннотация предназначена для обращения к отдельным частям multipart-запроса.
- @MatrixVariable - поддерживает т.н. матричные переменные.
5) Сервисные классы
Вот. Для полноты картины приведу сервисный интерфейс и его реализацию.
Бин с сервисной бизнес-логикой будет автоматически создан и подставлен в
переменную sessionProcessor. Это как раз и позволяет сделать контроллер
простым и неперегруженным.
package by.father.spring.mvc;и
public interface SessionProcessor {
public Long open(String login, String pass);
public void close(Long session);
}
package by.father.spring.mvc;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Service;
import javax.annotation.PostConstruct;
@Service
public class SessionProcessorImpl implements SessionProcessor {
private static final Logger logger = LoggerFactory.getLogger(SessionProcessorImpl.class);
@PostConstruct
public void setUp() {
logger.info("I'm created.");
}
@Override
public Long open(String login, String pass) {
Long sessionId = System.currentTimeMillis();
logger.info("Open session for {} / {}, session ID is {}.", new Object[]{login, pass, sessionId});
return sessionId;
}
@Override
public void close(Long session) {
logger.info("Close session {}.", session);
}
}
6) Итог
Итого, что мы получили? Несколько строк в xml-конфигурации позволяют
перенести большую часть работы на spring framework - по созданию
объектов, их привязке, маппингу URI на методы и пр. В контроллере
содержится только самый необходимый "наш" код. При
обращении по URI вызывается подходящий метод, которому поступают
также и необходимые ему параметры. Метод вызывает сервисную логику, а
затем возвращает ответ клиенту.
spring в данном случае позволяет разработчику избавиться от многих
рутинных действий по подъёму/запуску/маппингу HTTP-сервера и
сосредоточиться на прикладной разработке.
Комментариев нет:
Отправить комментарий