Рубрика «rest» - 3

В первой части нашего цикла статей «Пишем блог на микросервисах» мы описали общий подход к решению задачи.

Теперь пришла очередь API Gateway или API GW.

В нашем c ptimofeev API GW мы реализуем следующие функции:

  • Конвертация REST запросов в gRPC запросы и наоборот.
  • Логирование запросов.
  • Аутентификация запросов.
  • Присвоение каждому запросу Trace ID для дальнейшей передачи его между микросервисами по всей цепочке выполнения запроса.

Читать полностью »

В этой статье хочу поделится нашими c SergeyMaslov наработками решения типовых задач с использованием микросервисной архитектуры на примере задачи «создание блога» (в надежде, что читатель представляет как устроен блог и это не должно вызывать вопросов по функциональности:)
Читать полностью »

Сегодняшняя статья рассмотрит основные вопросы про REST в Spring. Она будет особенно полезна для начинающих программистов.

Официальный гид от Pivotal, в котором написано про темы для подготовки.

Подготовка к Spring Professional Certification. Spring REST - 1

Оглавление

  1. Внедрение зависимостей, контейнер, IoC, бины
  2. AOP (аспектно-ориентированное программирование)
  3. JDBC, транзакции, JPA, Spring Data
  4. Spring Boot
  5. Spring MVC
  6. Spring Security
  7. REST
  8. Тестирование


Читать полностью »

В прошлом посте мы рассказывали о том, как и почему мы в Acronis делаем аннотации к микросервисам, и обещали поделиться своей практикой применения единого формата API для всей платформы Acronis Cyber Platform. Сегодня мы расскажем про свой опыт статических проверок аннотаций – aka первый шаг на пути внедрения аннотаций в компании.

Что можно делать с аннотациями контрактов микросервисов? - 1
Читать полностью »

28 сентября на конференции RubyRussia DevRel компании Evrone Григорий Петров расскажет о том, как общаются микросервисы. В сегодняшнем интервью Иван Соловьев поговорил с Григорием о теме его предстоящего выступления и не только об этом.

image

Расскажи о себе, чем ты занимаешься в Evrone?
Читать полностью »

Предыстория

Несколько месяцев назад поступила задача по написанию HTTP API работы с продуктом компании, а именно обернуть все запросы с помощью RestTemplate и последующим перехватом информации от приложения и модификации ответа. Примерная реализация сервиса по работе с приложением была таковая:

        if (headers == null) {
            headers = new HttpHeaders();
        }

        if (headers.getFirst("Content-Type") == null) {
            headers.add("Content-Type", MediaType.APPLICATION_JSON_VALUE);
        }

        HttpEntity<Object> entity;
        if (body == null) {
            entity = new HttpEntity<>(headers);
        } else {
            entity = new HttpEntity<>(body, headers);
        }

        final String uri = String.format("%s%s/%s", workingUrl, apiPath, request.info());

        final Class<O> type = (Class<O>) request.type();
        final O response = (O)restTemplate.exchange(uri, request.method(), entity, type);

… простенький метод, принимающий тип, тело и заголовки запроса. И все бы хорошо, но выглядело как костыль и не особо юзабельно в контексте Spring.
И пока товарищи джуны писали "костыли" в своих ветках, мне пришла в голову гениальнейшая идея — а почему бы не писать эти запросы "в одну строчку" (like Feign).

Идея

У нас в руках имеется мощный DI контейнер Spring, так почему бы не использовать его функционал в полной мере? В частности инициализации Data репозиториев на примере Jpa. Предо мной стояла задача инициализация класса типа интерфейс в контексте Spring и три варианта решения перехвата вызова метода, как типичной реализации — Aspect, PostProcess и BeanDefinitionRegistrar.

Кодовая база

Первым делом — аннотации, куда же без них, иначе как конфигурировать запросы.

1) Mapping — аннотация, идентифицирующая интерфейс как компонент HTTP вызовов.

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Mapping {
    /**
     * Registered service application name, need for config
     */
    String alias();
}

Читать полностью »

Шпаргалки по безопасности: REST - 1

REST — чрезвычайно популярная архитектура веб-приложений. Для вызова функций на сервере используются обычные HTTP-запросы с задаваемыми параметрами (для структуризации параметров обычно используют JSON или XML), при этом, строгого стандарта для REST-архитектуры не существует, что добавляет ей гибкости (и, конечно, немного хаоса).
Читать полностью »

Самодокументируемый REST сервер (Node.JS, TypeScript, Koa, Joi, Swagger) - 1

Про преимущества и недостатки REST написано уже довольно много статей (и еще больше в комментариях к ним) ). И если уж так вышло, что вам предстоит разработать сервис, в котором должна быть применена именно эта архитектура, то вы обязательно столкнетесь с ее документированием. Ведь, создавая каждый метод, мы конечно же понимаем, что другие программисты будут к этим методам обращаться. Поэтому документация должна быть исчерпывающей, а главное — актуальной.

Добро пожаловать под кат, где я опишу, как мы решали эту задачу в нашей команде.
Читать полностью »

Принципы построения REST JSON API - 1 Эта памятка писалась для внутренних нужд (открыть глаза менее опытным в вебе коллегам). Но, т.к. я насмотрелся велосипедов от довольно уважаемых, казалось бы, контор, — выкладываю на хабр. Мне кажется, многим будет полезно.

Зачем

Надеюсь, читающий уже понимает, зачем ему вообще нужен именно REST api, а не какой-нибудь монстр типа SOAP. Вопрос в том, зачем соблюдать какие-то стандарты и практики, если браузеры вроде бы позволяют делать что хочешь.

  • Стандарт HTTP это стандарт. Его несоблюдение вредно для кармы и ведёт к постоянным проблемам с безопасностью, кэшированием и прочими "закидонами" браузеров, которые совсем не закидоны, а просто следование стандарту.
  • Велосипеды со всякими {error: "message","result":...} невозможно нормально тестировать и отлаживать
  • Поддержка большим количеством готовых клиентских библиотек на все случаи жизни. Те, кто будет вашим api пользоваться, скажут большое человеческое спасибо.
  • Поддержка автоматизированного интеграционного тестирования. Когда сервер на любые запросы отдаёт 200 ОК — ну, это такое себе развлечение.

Читать полностью »

REST? Возьмите тупой JSON-RPC - 1
В последнее время на Хабре разгорелось много споров по поводу того, как правильно готовить REST API.

Вместо того, чтобы бушевать в комментариях, подумайте: а нужен ли вам REST вообще?
Что это — осознанный выбор или привычка?

Возможно, именно вашему проекту RPC-like API подойдет лучше?

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js