Кроме того, ссылка, которую я спрятал в углублениях моих закладок, может представлять интерес для тех, кто интересуется, действительно ли ваша архитектура действительно RESTful или просто в том же стиле RPC с высокой связью, который REST пытается облегчить. Рой Филдинг, который написал свою диссертацию по REST, активно утверждает, что гиперссылки в представлениях ресурсов являются обязательными для стилей REST, и еще больше проясняет неопределенности, связанные с реализацией REST.
Исходный код этого примера можно найти в моем репозитории github.
Fuse Mediation Router — это усиленная версия Apache Camel корпоративного уровня FuseSource , предоставляющая удобный DSL для описания интеграций, посредников и маршрутизации. Это бесплатно, с открытым исходным кодом, и имеет лицензию Apache. Для тех, кто не знаком с Mediation Router / Camel, ознакомьтесь с введением Джона Анстея (соавтора Camel в действии ) в Зоне корпоративной интеграции DZone: Apache Camel: Integration Nirvana .
Мы будем использовать посреднический маршрутизатор, чтобы помочь написать простую интеграцию между конечной точкой REST и файлами ресурсов в файловой системе. Я буду использовать компонент camel-cxfrs для предоставления конечной точки REST и буду использовать компонент camel-file для чтения каталога в файловой системе. Цель этого примера — описать конфигурацию, необходимую для предоставления интерфейса REST через посреднический маршрутизатор, каким-либо образом интегрироваться с бэкэндом, преобразовать данные в соответствующий ответ REST и отправить ответ обратно.
Для начала давайте сосредоточимся на том, как настроить конечную точку REST. Для этого вы должны создать ресурс JAX-RS, который описывает методы java, которые будут действовать как конечные точки REST. Этот пример кода требует знакомства с Java API для веб-служб RESTful, также известного как JAX-RS. Для тех, кто незнаком, вот несколько хороших руководств, которые помогут понять JAX-RS.
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
@Path("/customerservice/")public class CustomerServiceResource {// NOTE: The instance member variables will not be available to the// Camel Exchange. They must be used as method parameters for them to// be made available@Contextprivate UriInfo uriInfo;public CustomerServiceResource() {}@GET@Path("/customers/{id}/")@Produces("text/xml")public Customer getCustomer(@PathParam("id") String id) { return null;}@PUT@Path("/customers/")public Response updateCustomer(Customer customer) { return null;}} |
Как вы можете видеть, аннотации — это аннотации JAX-RS, которые описывают операции, методы HTTP и типы MIME, связанные с конечной точкой REST. Обратите внимание, что все возвращаемые значения равны нулю, так как этот класс фактически не будет использоваться для обработки запросов, поступающих в конечную точку; маршруты-посредники будут отвечать за обработку и ответ. Тем не менее, обратите внимание, что элементы экземпляра недоступны для обменов посреднического маршрутизатора, т. Е. Любые элементы экземпляра, введенные с помощью аннотаций JAX-RS @Context, не будут доступны. Чтобы сделать их доступными, добавьте их в качестве параметров в ваши методы.
Объявление конечной точки CXF-RS с помощью посреднического маршрутизатора можно выполнить одним из двух способов: непосредственно в конфигурации конечной точки, например так:
Создание этого непосредственно в конфигурации требует меньше конфигурации XML, но предлагает ограниченную гибкость. Другой вариант — создать отдельный компонент, отвечающий за конечную точку, а затем сослаться на него в конфигурации конечной точки:
|
1
|
from("cxfrs:bean:rsServer") |
Бин rsServer должен быть определен в контексте верблюда. Пример:>
|
1
2
|
serviceClass="com.fusesource.samples.CustomerServiceResource"/> |
Этот подход позволяет отделить конфигурацию конечной точки и позволяет быть более быстрым и менее подробным в конфигурации конечной точки. Обе опции показаны в примере кода, хотя используется первая опция.
Вот и вся конфигурация, необходимая для предоставления конечной точки REST посредническим маршрутизатором. Довольно просто. Следующим шагом является использование файла из файловой системы на основе того, что поступает из конечной точки REST. Содержимое файла будет возвращено клиенту вызова REST. Для этого мы используем компонент camel-file и обогащаем Exchange вызовом pollEnrich в DSL:
|
1
2
|
.setHeader(Exchange.FILE_NAME, simple("test-${body}.xml")).pollEnrich("file:src/data?noop=true", 1000, new CustomerEnricher()) |
Мы не можем использовать какие-либо динамические выражения в вызове pollEnrich, поэтому мы устанавливаем заголовок, который компонент файла понимает, прежде чем мы сделаем обогащение. В этом случае тело сообщения REST является идентификатором, который можно использовать для шаблонирования ресурса файловой системы.
Наконец, мы можем добавить к маршруту дополнительную обработку:
|
1
|
.process(new CustomerServiceProcessor()) |
Цель этого примера, как описано выше, состоит в том, чтобы показать, как сконфигурировать конечную точку и подключить ее к дальнейшей обработке посреднического маршрутизатора. Обратите внимание, что шаблон обмена сообщениями (MEP) для конечной точки REST является InOut и ожидает ответа. Пример не предназначен для того, чтобы быть законченным комплексным решением, поскольку оно будет варьироваться в зависимости от предполагаемой функциональности. Пожалуйста, обратите внимание выше на ссылки на обсуждения Роя о том, что такое REST, а что нет.
Если я что-то пропустил или вам нужно больше пояснений по поводу примера, напишите мне комментарий, и мы сможем обсудить.
Ссылка: конечная точка REST для интеграции с использованием Apache Camel от нашего партнера по JCG Кристиана Поста в блоге