В этом руководстве мы создадим REST API поиска/фильтрации с использованием Spring Data JPA и спецификаций.
Мы начали рассматривать язык запросов в первой статье этой серии с решения на основе критериев JPA.
Итак, зачем язык запросов? Потому что поиска/фильтрации наших ресурсов по очень простым полям недостаточно для слишком сложных API. Язык запросов является более гибким и позволяет нам фильтровать именно те ресурсы, которые нам нужны.
пользователя Вызов внешних служб через конечную точку REST — обычное действие, которое стало очень простым благодаря таким библиотекам, как Feign . Однако во время таких звонков многое может пойти не так. Многие из этих проблем случайны или временны.
В этом руководстве мы узнаем, как повторять неудачные вызовы и создавать более отказоустойчивые клиенты REST.
Во-первых, давайте создадим простой конструктор клиента Feign, который позже мы добавим в повторные попытки. Мы будем использовать OkHttpClient в качестве HTTP-клиента. Кроме того, мы будем использовать GsonEncoder и GsonDecoder для кодирования и декодирования запросов и ответов. Наконец, нам нужно указать URI цели и тип ответа:
В этом руководстве мы интегрируем базовые метрики в Spring REST API .
Мы создадим метрическую функциональность сначала с помощью простых фильтров сервлетов, а затем с помощью модуля Spring Boot Actuator.
файл.xmlНачнем с регистрации фильтра — « MetricFilter » — в файле web.xml нашего приложения:
В этом руководстве мы увидим разницу между JAX-RS и Spring MVC для разработки REST API.
Чтобы стать частью мира JAVA EE , функция должна иметь спецификацию, совместимую реализацию и TCK . Соответственно, JAX-RS — это набор спецификаций для построения REST-сервисов . Наиболее известными эталонными реализациями являются RESTEasy и Jersey .
Теперь давайте немного познакомимся с Джерси, реализуя простой контроллер:
В этой статье мы рассмотрим Spring REST Shell и некоторые его функции.
Это расширение Spring Shell, поэтому мы рекомендуем сначала прочитать о нем .
Spring REST Shell — это оболочка командной строки, предназначенная для облегчения работы с ресурсами REST, совместимыми с Spring HATEOAS.
Спецификация URI RFC 3986 определяет параметры пути URI как пары имя-значение. Матричные переменные — это термин, придуманный Spring, и альтернативная реализация для передачи и анализа параметров пути URI.
Поддержка матричных переменных стала доступна в Spring MVC 3.2 и предназначена для упрощения запросов с большим количеством параметров .
В этой статье мы покажем, как можно упростить сложные запросы GET, которые используют либо переменные, либо необязательные параметры пути внутри различных сегментов пути URI.
В этом руководстве мы рассмотрим несколько возможных способов реализации тайм-аутов запросов для Spring REST API.
Мы обсудим преимущества и недостатки каждого из них. Время ожидания запроса полезно для предотвращения плохого взаимодействия с пользователем, особенно если есть альтернатива, которую мы можем использовать по умолчанию, когда ресурс занимает слишком много времени. Этот шаблон проектирования называется шаблоном Circuit Breaker , но мы не будем подробно на нем останавливаться.
@Транзакционные тайм- аутыОдин из способов, которым мы можем реализовать тайм-аут запроса для вызовов базы данных, — это воспользоваться аннотацией Spring @Transactional . У него есть свойство тайм -аута , которое мы можем установить. Значение по умолчанию для этого свойства равно -1, что эквивалентно полному отсутствию времени ожидания. Для внешней настройки значения тайм-аута вместо этого необходимо использовать другое свойство — timeoutString .
В этом руководстве мы разберемся с методологией приложения с двенадцатью факторами .
Мы также поймем, как разработать микросервис с помощью Spring Boot. В процессе мы увидим, как применять методологию двенадцати факторов для разработки такого микросервиса.
Методология двенадцати факторов представляет собой набор из двенадцати передовых методов разработки приложений, предназначенных для работы в качестве службы . Первоначально это было разработано Heroku для приложений, развернутых в качестве сервисов на их облачной платформе еще в 2011 году. Со временем это оказалось достаточно общим для любой разработки программного обеспечения как услуги (SaaS).
В этой статье описывается, как реализовать согласование содержимого в проекте Spring MVC.
Как правило, существует три варианта определения типа носителя запроса:
(Устарело) Использование суффиксов URL (расширений) в запросе (например , .xml/.json ), ?format=json )Accept в запросе По умолчанию это порядок, в котором менеджер согласования содержимого Spring попытается использовать эти три стратегии. И если ни один из них не включен, мы можем указать откат к типу контента по умолчанию.
В этом руководстве мы рассмотрим преобразования, которые должны происходить между внутренними объектами приложения Spring и внешними DTO (объектами передачи данных), которые публикуются обратно клиенту.
Давайте начнем с представления основной библиотеки, которую мы собираемся использовать для преобразования объекта в DTO, ModelMapper .