Библиотека Java разработчика

🎮 Анатомия REST Controller: Входящие и Исходящие

Раньше, чтобы вернуть JSON, нужно было танцевать с бубном. В Spring Boot это делается "из коробки" благодаря библиотеке Jackson, которая тихо работает в фоне.

1️⃣ @RestController vs @Controller

Это первый вопрос на собеседовании.

🔴

@Controller: Олдскул. Используется, когда мы возвращаем HTML-страницы (Thymeleaf, JSP). Чтобы вернуть JSON, нужно над каждым методом вешать @ResponseBody.

🔴

@RestController: Современный стандарт для REST API.
🔴Это просто @Controller + @ResponseBody над всеми методами.
🔴Всё, что возвращает метод, автоматически превращается в JSON.

2️⃣ Принимаем данные (3 главных способа)

Как вытащить информацию из запроса?

А. Из пути URL (@PathVariable)
Используем, когда параметр - это часть адреса ресурса.

🔴

URL: GET /users/42

🔴

Код:


@GetMapping("/users/{id}")
public User getById(@PathVariable Long id) { ... }

Б. Из параметров запроса (@RequestParam)
Используем для фильтрации, сортировки или опциональных параметров.

• URL: GET /users?role=ADMIN&age=25
• Код:


@GetMapping("/users")
public List<User> search(
    @RequestParam String role, 
    @RequestParam(required = false) Integer age // Опционально
) { ... }

В. Из тела запроса (@RequestBody)
Используем для отправки сложных объектов (обычно в POST/PUT запросах). Spring возьмет JSON и сам превратит его в Java-объект (DTO).

• JSON: { "name": "Alex", "email": "a@b.com" }
• Код:


@PostMapping("/users")
public User create(@RequestBody UserDto userDto) { ... }

3️⃣ Управляем ответом (ResponseEntity)

Просто вернуть объект User, это хорошо (статус будет 200 OK). Но что, если мы хотим вернуть 404 (Not Found) или 201 (Created)?

Для этого используем обертку ResponseEntity<T>.

💻 Пример: Идеальный контроллер


@RestController
@RequestMapping("/api/v1/users") // Общий префикс для всех методов
public class UserController {

    private final UserService service; // Внедряем через конструктор

    public UserController(UserService service) {
        this.service = service;
    }

    // 1. Получить всех (GET 200 OK)
    @GetMapping
    public List<User> getAll() {
        return service.findAll();
    }

    // 2. Найти одного (с управлением статусом)
    @GetMapping("/{id}")
    public ResponseEntity<User> getOne(@PathVariable Long id) {
        return service.findById(id)
                .map(user -> ResponseEntity.ok(user)) // 200 OK
                .orElse(ResponseEntity.notFound().build()); // 404 Not Found
    }

    // 3. Создать (POST 201 Created)
    @PostMapping
    public ResponseEntity<User> create(@RequestBody UserDto dto) {
        User created = service.save(dto);
        return ResponseEntity.status(HttpStatus.CREATED).body(created);
    }
}

⚡ Jackson Magic (Pro-Tip)

Иногда вам не нужно отдавать все поля объекта (например, пароль).
Не пишите код для скрытия! Используйте аннотации Jackson прямо в DTO:

• @JsonIgnore - поле не попадет в JSON.
• @JsonProperty("full_name") - поле fullName в Java станет full_name в JSON.

🔥 Итог

• Используйте @RestController для API.
• @PathVariable - для ID (/users/1).
• @RequestParam - для фильтров (/users?sort=name).
• @RequestBody - для больших данных (JSON).
• Возвращайте ResponseEntity, чтобы контролировать HTTP-статусы.

#SpringBoot #REST #Controller #API #Java

📲 Мы в MAX

👉@BookJava

Please open Telegram to view this post

VIEW IN TELEGRAM

👍6❤1

1.21K views07:32

Библиотека Java разработчика

🔌 Проектирование API: REST, GraphQL или gRPC?

🧱 1. REST (Классика и Стандарт)

REST (Representational State Transfer) - это де-факто стандарт интернета. Большинство публичных API (GitHub, Stripe, Telegram) построены на нем.

Суть: В центре всего находится Ресурс (Существительное). А действия над ним выполняются через стандартные HTTP-методы (Глаголы).
• GET /users/123 - Дай мне пользователя 123.
• POST /users - Создай пользователя.
• DELETE /users/123 - Удали пользователя.

✅ Плюсы:

• Простота: Понятен всем, легко тестировать через Postman или браузер.

• Кэширование: Идеально работает с CDN (о которых мы говорили раньше), так как использует стандартные механизмы HTTP.

❌ Минусы:

• Over-fetching (Избыточность): Мобильному приложению нужно только имя пользователя, но метод GET /users/1 возвращает огромный JSON на 50 полей (с адресами, датами и т.д.). Вы тратите трафик впустую.

• Under-fetching (Недостаточность) и проблема N+1: Чтобы показать профиль пользователя и его 10 последних постов, фронтенду придется сделать 1 запрос к /users/1 и еще 10 запросов к /posts?userId=1. Это медленно.

🕸️ 2. GraphQL (Мечта Фронтендера)

Разработан в Facebook для решения проблем REST при слабом мобильном интернете.

Суть: У вас есть всего один Endpoint (обычно POST /graphql). Клиент сам пишет запрос-схему, где указывает, какие конкретно поля ему нужны.

Запрос клиента:


query {
  user(id: "123") {
    name
    email
    posts(last: 10) {
      title
    }
  }
}

Ответ сервера: Вернется JSON строго с именем, email и 10 заголовками постов. Ни одним байтом больше!

✅ Плюсы:

• Решает проблемы Over-fetching и Under-fetching. Один запрос = ровно те данные, что нужны для отрисовки экрана.

• Быстрая итерация фронтенда: UI-команде больше не нужно просить бэкендеров написать новый endpoint /users-with-posts-and-comments.

❌ Минусы:

• Сложность кэширования: Так как всё идет через один URL POST /graphql, вы не можете просто закэшировать это на уровне CDN (Cloudflare).

• Угроза для Базы Данных: Если клиент напишет слишком глубокий вложенный запрос (Пользователь -> Посты -> Комментарии -> Авторы комментариев -> Их посты), ваша БД просто "ляжет".

🚀 3. gRPC (Спидраннер для Микросервисов)

Разработан в Google. Если REST и GraphQL общаются с помощью удобочитаемого текста (JSON) поверх старого HTTP/1.1, то gRPC ломает эти правила.

Суть: Вы вызываете функцию на другом сервере так, будто она лежит в вашем собственном коде.
Он использует HTTP/2 (поддерживает стриминг) и Protobuf (Protocol Buffers).
Protobuf - это бинарный формат. Вместо того чтобы передавать ключи "name": "Alex", он передает просто байты по заранее оговоренной жесткой схеме (.proto файл).

✅ Плюсы:

• Невероятная скорость: Бинарный формат весит в разы меньше JSON и парсится процессором мгновенно. gRPC работает до 10 раз быстрее REST.

• Строгая типизация: Вы описываете контракты в .proto файле, и из него автоматически генерируется код и для Java-бэкенда, и для Python-клиента. Никаких ошибок "ожидал строку, пришло число".

• Стриминг: Можно открыть соединение и непрерывно лить данные в обе стороны.

❌ Минусы:

• Не читается человеком: Вы не можете просто открыть консоль браузера и посмотреть payload, там будут непонятные бинарные символы.

• Плохая поддержка браузерами: Напрямую из JavaScript в браузере gRPC вызвать сложно (нужен прокси grpc-web), поэтому для публичного фронтенда его почти не используют.

В идеальной современной архитектуре:
Мобилка общается с API Gateway по GraphQL —> Gateway общается с внутренними микросервисами по gRPC.

#SystemDesign #API #REST #GraphQL #gRPC #Java

📲 Мы в MAX

👉@BookJava

❤8👍6

925 views04:51

About

Blog

Apps

Platform