Давным-давно в одной далёкой-далёкой... проекте, понадобилось мне сделать обработку http-запросов на Netty. К сожалению, стандартных удобных механизмов для маппинга http-запросов в Netty не нашлось (да и этот фреймвёрк совсем не для того), поэтому, было решено реализовать собственный механизм.
Если читатель начал беспокоиться о судьбе проекта, то не стоит, с ним всё хорошо, т.к. в дальнейшем было решено переписать веб-сервис на фреймвёрке более заточенном под RESTful сервисы, без использования собственных велосипедов. Но наработки остались, и они могут быть кому-нибудь полезными, поэтому хотелось бы ими поделиться.
Netty — это фреймвёрк, позволяющий разрабатывать высокопроизводительные сетевые приложения. Подробнее о нём можно прочитать на сайте проекта.
Для создания сокет-серверов Netty предоставляет весьма удобный функционал, но для создание REST-серверов данный функционал, на мой взгляд, является не очень удобным.
Обработка запросов с использованием стандартного механизма Netty
Для обработки запросов в Netty необходимо отнаследоваться от класса ChannelInboundHandlerAdapter
и переопределить метод channelRead
.
public class HttpMappingHandler extends ChannelInboundHandlerAdapter {
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) {
}
}
Для получения необходимой при обработке http-запросов информации объект msg
можно привести к HttpRequest
.
HttpRequest request = (HttpRequest) msg;
После этого можно получить какую-либо информацию из этого запроса. Например, URL-адрес запроса.
String uri = request.uri();
Тип запроса.
HttpMethod httpMethod = request.method();
И контент.
ByteBuf byteBuf = ((HttpContent) request).content();
Контентом может быть, например, json, переданный в теле POST
-запроса. ByteBuf
— это класс из библиотеки Netty, поэтому json-парсеры вряд ли смогут с ним работать, но его очень просто можно привести к строке.
String content = byteBuf.toString(StandardCharsets.UTF_8);
Вот, в общем-то, и всё. Используя указанные выше методы, можно обрабатывать http-запросы. Правда, обрабатывать всё придётся в одном месте, а именно в методе channelRead
. Даже если разнести логику обработки запросов по разным методам и классам, всё равно придётся сопоставлять URL с этими методами где-то в одном месте.
Маппинг запросов
Что ж, как видим, вполне можно реализовать маппинг http-запросов, используя стандартный функционал Netty. Правда, будет это не очень удобно. Хотелось бы как-то полностью разнести обработку http-запросов по разным методам (например, как это сделано в Spring). С помощью рефлексии была предпринята попытка реализовать подобный подход. Получилась из этого библиотека num. С её исходным кодом можно ознакомиться по ссылке.
Для использования маппинга запросов с помощью библиотеки num достаточно отнаследоваться от класса AbstractHttpMappingHandler
, после чего в этом классе можно будет создавать методы-обработчики запросов. Главное требование к данным методам — это чтобы они возвращали FullHttpResponse
или его наследников. Показать, по какому http-запросу будет вызываться данный метод, можно с помощью аннотаций:
@Get
@Post
@Put
@Delete
Имя аннотации показывает то, какой тип запроса будет вызван. Поддерживается четыре типа запросов: GET
, POST
, PUT
и DELETE
. В качестве параметра value
в аннотации необходимо указать URL-адрес, при обращении на который будет вызываться нужный метод.
Пример того, как будет выглядеть обработчик GET
-запроса, который возвращает строку Hello, world!
.
public class HelloHttpHandler extends AbstractHttpMappingHandler {
@Get("/test/get")
public DefaultFullHttpResponse test() {
return new DefaultFullHttpResponse(HttpVersion.HTTP_1_1, OK,
Unpooled.copiedBuffer("Hello, world!", StandardCharsets.UTF_8));
}
}
Параметры запросов
Передача параметров из запроса в метод-обработчик осуществляется также с помощью аннотаций. Для этого можно воспользоваться одной из следующих аннотаций:
@PathParam
@QueryParam
@RequestBody
@PathParam
Для передачи path-параметров используется аннотация @PathParam
. При её использовании в качестве параметра value
аннотации необходимо указать название параметра. Кроме того, название параметра необходимо указать и в URL запроса.
Пример того, как будет выглядеть обработчик GET
-запроса, в который передаётся path-параметр id
и который возвращает этот параметр.
public class HelloHttpHandler extends AbstractHttpMappingHandler {
@Get("/test/get/{id}")
public DefaultFullHttpResponse test(@PathParam(value = "id") int id) {
return new DefaultFullHttpResponse(HttpVersion.HTTP_1_1, OK,
Unpooled.copiedBuffer(id, StandardCharsets.UTF_8));
}
}
@QueryParam
Для передачи query-параметров используется аннотация @QueryParam
. При её использовании в качестве параметра value
аннотации необходимо указать название параметра. Обязательностью параметра можно управлять с помощью параметра аннотации required
.
Пример того, как будет выглядеть обработчик GET
-запроса, в который передаётся query-параметр message
и который возвращает этот параметр.
public class HelloHttpHandler extends AbstractHttpMappingHandler {
@Get("/test/get")
public DefaultFullHttpResponse test(@QueryParam(value = "message") String message) {
return new DefaultFullHttpResponse(HttpVersion.HTTP_1_1, OK,
Unpooled.copiedBuffer(message, StandardCharsets.UTF_8));
}
}
@RequestBody
Для передачи тела POST
-запросов используется аннотация @RequestBody
. Поэтому и использовать её разрешается только в POST
-запросах. Предполагается, что в качестве тела запроса будут передаваться данные в формате json. Поэтому для использования @RequestBody
необходимо в конструктор класса-обработчика передать реализацию интерфейса JsonParser
, которая будет заниматься парсингом данных из тела запроса. Также в библиотеке уже имеется реализация по умолчанию JsonParserDefault
. В качестве парсера данная реализация использует jackson
.
Пример того, как будет выглядеть обработчик POST
-запроса, в котором имеется тело запроса.
public class HelloHttpHandler extends AbstractHttpMappingHandler {
@Post("/test/post")
public DefaultFullHttpResponse test(@RequestBody Message message) {
return new DefaultFullHttpResponse(HttpVersion.HTTP_1_1, OK,
Unpooled.copiedBuffer("{id: '" + message.getId() +"', msg: '" + message.getMessage() + "'}",
StandardCharsets.UTF_8));
}
}
Класс Message
выглядит следующим образом.
public class Message {
private int id;
private String message;
public Message() {
}
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
public String getMessage() {
return message;
}
public void setMessage(String message) {
this.message = message;
}
}
Обработка ошибок
Если при обработке запросов возникнет какой-либо Exception
и он не будет перехвачен в коде методов-обработчиков, то вернётся ответ с 500-ым кодом. Для того чтобы написать какую-то свою логику по обработке ошибок, достаточно переопределить в классе-обработчике метод exceptionCaught
.
public class HelloHttpHandler extends AbstractHttpMappingHandler {
@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
super.exceptionCaught(ctx, cause);
ctx.writeAndFlush(new DefaultFullHttpResponse(HttpVersion.HTTP_1_1, HttpResponseStatus.INTERNAL_SERVER_ERROR));
}
}
Заключение
Вот, в общем-то, и всё. Надеюсь, это было интересно и будет кому-нибудь полезным.
Код примера http-сервера на Netty с использованием библиотеки num доступен по ссылке.
tuxi
Реализация обработки разных методов хттп запросов практически в любом сервлет-контейнере представлена. Это упростило бы разработку. У меня вопрос по делу: Вы с вебсокетами на netty пробовали играться? Насколько стабильно все работает?
1_van
Пробовал. Проблем не возникало, вроде бы всё стабильно, а ещё весьма удобно.:)
tuxi
Что удобно — это понятно :) Мне интересно, насколько устойчиво держится канал со страницей, например в гугл хроме, которую оставили открытой и активной, но нет никакой пользовательской активности. Таких кейсов не было?
APXEOLOG
У меня как раз такой кейс. По моему опыту (google chrome <-> netty websocket server):
tuxi
Вот такая же вялотекущая фихня. Не амазон, но тоже nginx. Пока не критично, но начинает, как говорится, задевать самолюбие.
1_van
Не-а. Были только сервер, написанный на Netty и клиенты на Netty. Там всё было вообще отлично.:)
BugM
Хорошо все держится, если keep alive слать регулярно. Без keep alive все плохо.