В этой статье мы рассмотрим взаимодействие между интерфейсным приложением и REST API, развернутыми отдельно .
Цель состоит в том, чтобы обойти ограничения CORS и политики одинакового происхождения для браузера и позволить пользовательскому интерфейсу вызывать API, даже если они не имеют одного и того же источника.
В основном мы создадим два отдельных приложения — приложение пользовательского интерфейса и простой REST API, и мы будем использовать прокси- сервер Zuul в приложении пользовательского интерфейса для проксирования вызовов к REST API.
Zuul — это маршрутизатор на основе JVM и балансировщик нагрузки на стороне сервера от Netflix. И Spring Cloud имеет хорошую интеграцию со встроенным прокси-сервером Zuul — это то, что мы будем использовать здесь.
В этом руководстве показано, как реализовать обработку исключений с помощью Spring для REST API. Мы также получим небольшой исторический обзор и посмотрим, какие новые опции были представлены в разных версиях.
До Spring 3.2 двумя основными подходами к обработке исключений в приложении Spring MVC были HandlerExceptionResolver или аннотация @ExceptionHandler . У обоих есть явные недостатки.
Начиная с версии 3.2, у нас есть аннотация @ControllerAdvice для устранения ограничений предыдущих двух решений и продвижения единой обработки исключений во всем приложении.
Теперь в Spring 5 представлен класс ResponseStatusException — быстрый способ базовой обработки ошибок в наших REST API.
Все они имеют одну общую черту: они очень хорошо справляются с разделением задач . Обычно приложение может генерировать исключения, чтобы указать на какой-либо сбой, который затем будет обрабатываться отдельно.
Маршрутизация — это распространенная концепция, которая используется в большинстве сред веб-разработки, включая Spring MVC .
Маршрут — это шаблон URL, который сопоставляется с обработчиком. Обработчик может быть физическим файлом, например загружаемым ресурсом в веб-приложении, или классом, обрабатывающим запрос, например контроллером в приложении MVC.
В этом руководстве мы рассмотрим аспект маршрутизации при разработке веб-приложений с помощью Play Framework .
Spring REST Docs создает документацию для служб RESTful, которая является точной и удобочитаемой. Он сочетает в себе рукописную документацию с автоматически сгенерированными фрагментами документов, созданными с помощью тестов Spring.
Одной из основных философий проекта является использование тестов для создания документации. Это гарантирует, что всегда создаваемая документация точно соответствует фактическому поведению API. Кроме того, выходные данные готовы для обработки Asciidoctor , цепочкой инструментов публикации, основанной на синтаксисе AsciiDoc. Это тот же инструмент, который используется для создания документации Spring Framework.
Эти подходы уменьшают ограничения, налагаемые другими фреймворками. Spring REST Docs создает точную, краткую и хорошо структурированную документацию. Затем эта документация позволяет потребителям веб-сервисов получать необходимую им информацию с минимальными усилиями.
В этом руководстве мы обсудим, что такое HAL и почему он полезен, прежде чем представить браузер HAL .
Затем мы воспользуемся Spring для создания простого REST API с несколькими интересными конечными точками и заполним нашу базу данных тестовыми данными.
Наконец, используя браузер HAL, мы изучим наш REST API и узнаем, как перемещаться по содержащимся в нем данным.
В настоящее время внешние и внутренние компоненты часто разделяют веб-приложение. Обычно мы предоставляем API в качестве внутреннего компонента для внешнего компонента или интеграции сторонних приложений.
В таком сценарии важно иметь правильные спецификации для серверных API. В то же время документация по API должна быть информативной, читабельной и простой для понимания.
Более того, справочная документация должна одновременно описывать каждое изменение в API. Выполнять это вручную — утомительное занятие, поэтому автоматизация процесса была неизбежна.
В этом руководстве мы рассмотрим Swagger 2 для веб-службы Spring REST , используя реализацию Springfox спецификации Swagger 2. Важно отметить, что последняя версия спецификации Swagger, теперь известная как OpenAPI 3.0, лучше поддерживается проектом Springdoc и должна использоваться для документирования Spring REST API .
Если вы не знакомы со Swagger, посетите его веб-страницу , чтобы узнать больше, прежде чем продолжить работу с этим руководством.
В этом руководстве мы узнаем , как работать с отношениями между сущностями в Spring Data REST .
Мы сосредоточимся на ресурсах ассоциации, которые Spring Data REST предоставляет для репозитория, учитывая каждый тип отношений, которые мы можем определить.
Чтобы избежать дополнительной настройки, мы будем использовать для примеров встроенную базу данных H2 . Мы можем найти список необходимых зависимостей в нашей статье Introduction to Spring Data REST .
Иногда нам нужно установить заголовки запросов в наших HTTP-вызовах при использовании Feign . Feign позволяет нам создавать HTTP-клиенты с простым декларативным синтаксисом.
В этом кратком руководстве мы увидим, как настроить заголовки запроса с помощью аннотаций. Мы также увидим, как включать общие заголовки запросов с помощью перехватчиков.
В этом руководстве мы будем использовать пример приложения книжного магазина , которое предоставляет конечные точки REST API.
LinkRest — это платформа с открытым исходным кодом для создания управляемых данными веб-сервисов REST. Он построен на основе JAX-RS и Apache Cayenne ORM и использует протокол сообщений на основе HTTP/JSON.
По сути, эта структура предназначена для предоставления простого способа предоставления нашего хранилища данных в Интернете.
В следующих разделах мы рассмотрим, как мы можем создать веб-службу REST для доступа к модели данных с помощью LinkRest .
Maven