Архитектура web API на Java

#java #архитектура #rest

Подскажите, пож, этапы создания грамотного АПИ на JAVA.(Или ткните в какойто мануал,
т.к. серфинг в гугле удовлетворяющего ответа не принес)

Как мне видится схема построения апи - 

-закидываем на вход XML, JSON, curl (в идеале и то и то) через HTTP 
   -демаршалим на сущности
   -настраиваем JDBC(JPA) коннектимся к БД
   -из десериализованных сущностей формируем запрос к БД
   -получаем ответ , сериализуем в XML/JSON
   -возвращаем ответ

Интересно по инструментарию, что оптимально юзать на каждом из этапов.
Удобнее ли для настройки коннекта с базой использовать ORM

Заранее спасибо.
    

Ответы

Ответ 1

Из постановки вопроса вырисовывается обычное веб-приложение, которое с одной стороны
работает с json/xml через HTTP, а с другой ползает в базу данных.

Получается 3 каноничных слоя: web-сервис, бизнес-логика и слой хранения данных. Эта
схема, на самом деле, широко рассмотрена со всех сторон в интернетах. Посмотрим еще раз.

Web-сервис

Это собственно и есть внешний API, все остальное - детали реализации. Чтобы принимать
запросы по HTTP потребуется web-сервер, наиболее популярные в среде Java это Jetty,
Apache Tomcat, Grizzly. Я бы для начала остановился на Jetty, его легко запускать с
минимумом конфигурации и легко встроить в ваше приложение, если потребуется. 

Далее нужно определиться с концепцией web-сервиса: будет ли это один из видов RPC
(SOAP, XML-RPC, JSON-RPC, Hessian, Apache Thrift) или REST: 


RPC легче для восприятия, так как похожи на обычный вызов локального метода, но они
прячут всю магию под капотом и, как правило, используют свои форматы передачи данных
(на основе xml/json или бинарные). API на основе RPC легко быстро спрототипировать:
обычно вы описываете обычный интерфейс, реализуете его серверную часть, все остальное
сделают за вас и даже сгенерируют заглушки для клиентского кода на определенном наборе
языков программирования.
REST строится вокруг идеи передачи состояния объектов между клиентом и сервером,
то есть оперирует объектами, а не действиями. Такой API хорошо ложится на CRUD, но
требует тщательного продумывания для более сложных кейсов. Он достаточно низкоуровневый
в том отношении, что вы сами определяете форматы данных, обработку ошибок, что добавляет
сложности. Но все это при правильном подходе позволяет легче масштабировать web-сервис
в дальнейшем.


Исходя из ваших требований (CRUD-операции и одновременная поддержка JSON и XML),
вам, вероятно, больше подойдет REST. Для Java существует спецификация JAX-RS, описывающая
стандартный способ создания REST-сервисов и ряд её реализаций: Jersey, Apache CXF,
Resteasy. Общая идея такова, что вы пишите обычные классы, принимающие и возвращающие
ваши объекты, развешиваете аннотации и веб-сервис готов:

@Path("/api")
@Produces({"application/json", "application/xml"})
@Consumes({"application/json", "application/xml"})
public class MyApi {

    @GET
    @Path("/foo/{id}")
    public Foo getFooById(@PathParam("id") Long id) { ... }

    @POST
    @Path("/foo")
    public Foo createFooById(Foo foo) { ... }
}


И вот мы уже можем через POST и GET создавать и получать экземпляры класса Foo. Маршаллинг
в json/xml и обратно нам прозрачно сделает библиотека Jackson.

Бизнес-логика

С этим все просто, это ваши классы, которые делают что-то полезное над передаваемыми
вверх-вниз объектами: валидируют или дополняют данные, бросают ошибки, создают уведомления,
взаимодействуют с файловой системой. Если коротко, выполняют непосредственную работу.

Возможно, для удобства управления вы захотите поместить классы в какой-либо DI контейнер:
Spring, EJB (только, если речь об энтерпрайзе) или связать чем-то более легковесным
вроде Guice.

Хранение данных

Про persistence-слой вы также без труда найдете массу информации. Выделите отдельные
классы (обычно из называют DAO - Data Access Objects), которые будут класть и доставать
объекты из БД. Тут вам в помощь JDBC, JPA, ORM-ы. Главное - представлять, что тот же
Hibernate тяжеловесный и достаточно сложный, и, если речь идет о десятке классов/таблиц,
проще будет покорячиться с JDBC (жизнь облегчат Spring-овый JdbcTemplate или симпатичная
библиотечка JDBI). Еще можете глянуть Spring Data - это такая глобальная абстракция
над любыми хранилищами (вдруг завтра вы решите хранить данные не в БД, а на другом
сервере, доступном через REST).

Еще один момент: не стоит поддаваться искушению отдавать экземпляры классы, которые
ORM вытащит из БД сразу в REST. На уровне веб-сервиса переложите их в транспортные
DTO-шки. Это избавит вас от боли в дальнейшем. Если лень перекладывать руками, можете
попробовать какой-нибудь Dozer (но его придется конфигурировать в свою очередь XML-ем).  

Синяя изолента

Посмотрим, какой выходит стек технологий:


Web-server: Jetty/Tomcat/Grizzly
Rest-endpoint: Jackson и Jersey/CXF/Resteasy
DI: Spring/Guice
Persistence: JDBC/JPA/ORM + опционально Spring JDBC/Spring Data/JDBI


Все это, конечно, нужно обложить логами. Сейчас популярно SLF4J + Logback. По вкусу
- сбор метрик, например, Codahale Metrics. 

Из описанных компонентов можно собрать как классическое web-приложение, завернутое
в war-файл, которое можно развернуть в сервлет-контейнере (Jetty, Tomcat) или на application-сервере,
так и standalone-приложение, со встроенным веб-сервером, которое можно таскать с места
на место и запускать из командной строки. 

Если вы захотите пойти по второму пути (сейчас модно писать независимые микросервисы)
стоит попробовать Spring Boot (Spring Initializr) или Dropwizard. Эти инструменты сгенерируют
всю необходимую обвязку, чтобы вы могли сосредоточиться на написании бизнес-логики.