Какой REST метод используешь для чтения сущности в CRUD-приложении?

REST методы для чтения в CRUD-приложении

Вопрос о REST методах - это базовое знание для любого Java разработчика, работающего с веб-приложениями. Правильное использование HTTP методов критично для построения масштабируемых и поддерживаемых API.

Основной метод: GET

Для чтения сущности используется HTTP GET метод. Это безопасный и idempotent метод, что означает:

• Не изменяет состояние на сервере
• Можно вызывать многократно с одинаковым результатом
• Безопасен для повторных запросов (нет side-effects)

// REST endpoint в Spring для чтения сущности
@RestController
@RequestMapping("/api/v1/users")
public class UserController {
    
    @Autowired
    private UserService userService;
    
    // GET /api/v1/users/{id} - получить одного пользователя
    @GetMapping("/{id}")
    public ResponseEntity<UserDto> getUser(@PathVariable Long id) {
        UserDto user = userService.findById(id);
        return ResponseEntity.ok(user);
    }
}

Варианты GET запросов

Вариант 1: Получить одну сущность по ID

GET /api/v1/users/123

@GetMapping("/{id}")
public ResponseEntity<UserDto> getUser(@PathVariable Long id) {
    return ResponseEntity.ok(userService.findById(id));
}

Вариант 2: Получить список сущностей (Collection)

GET /api/v1/users
GET /api/v1/users?page=0&size=10&sort=name,asc

@GetMapping
public ResponseEntity<Page<UserDto>> listUsers(
    @RequestParam(defaultValue = "0") int page,
    @RequestParam(defaultValue = "10") int size,
    @RequestParam(defaultValue = "id") String sort) {
    
    Pageable pageable = PageRequest.of(page, size, Sort.by(sort));
    Page<UserDto> users = userService.findAll(pageable);
    return ResponseEntity.ok(users);
}

Вариант 3: Получить вложенный ресурс

GET /api/v1/users/123/posts

@GetMapping("/{userId}/posts")
public ResponseEntity<List<PostDto>> getUserPosts(@PathVariable Long userId) {
    List<PostDto> posts = userService.getPostsByUserId(userId);
    return ResponseEntity.ok(posts);
}

CRUD методы и их назначение

В полной CRUD операции используются следующие HTTP методы:

Важные различия: PUT vs PATCH

Для обновления используются два метода, но назначение разное:

// PUT - полное обновление (замещение всей сущности)
@PutMapping("/{id}")
public ResponseEntity<UserDto> updateUser(
    @PathVariable Long id,
    @RequestBody UserDto userDto) {
    UserDto updated = userService.update(id, userDto);  // Заменить всё
    return ResponseEntity.ok(updated);
}

// PATCH - частичное обновление (только переданные поля)
@PatchMapping("/{id}")
public ResponseEntity<UserDto> patchUser(
    @PathVariable Long id,
    @RequestBody Map<String, Object> updates) {
    UserDto patched = userService.patch(id, updates);  // Обновить только что передано
    return ResponseEntity.ok(patched);
}

Правильная обработка GET в реальном проекте

В моём опыте я всегда следую этой практике:

@RestController
@RequestMapping("/api/v1/products")
public class ProductController {
    
    private final ProductService productService;
    private final ProductMapper mapper;
    
    public ProductController(ProductService productService, ProductMapper mapper) {
        this.productService = productService;
        this.mapper = mapper;
    }
    
    // Получить один продукт
    @GetMapping("/{id}")
    public ResponseEntity<ProductResponse> getProduct(@PathVariable UUID id) {
        try {
            Product product = productService.findById(id);  // Business logic
            return ResponseEntity.ok(mapper.toResponse(product));  // Маппинг
        } catch (NotFoundException e) {
            return ResponseEntity.notFound().build();  // 404
        }
    }
    
    // Получить список с пагинацией и фильтрацией
    @GetMapping
    public ResponseEntity<Page<ProductResponse>> listProducts(
        @RequestParam(required = false) String category,
        @RequestParam(defaultValue = "0") int page,
        @RequestParam(defaultValue = "20") int size,
        Pageable pageable) {
        
        Page<Product> products = productService.search(category, pageable);
        Page<ProductResponse> response = products.map(mapper::toResponse);
        return ResponseEntity.ok(response);
    }
}

Коды ответов (HTTP Status Codes)

Для GET операций используются следующие коды:

// 200 OK - успешное получение данных
GET /api/v1/users/1
Response: 200 OK
{
  "id": 1,
  "name": "John"
}

// 404 Not Found - сущность не найдена
GET /api/v1/users/999
Response: 404 Not Found

// 400 Bad Request - неправильные параметры
GET /api/v1/users?page=-1
Response: 400 Bad Request

// 401 Unauthorized - не авторизован
GET /api/v1/users (без токена)
Response: 401 Unauthorized

// 403 Forbidden - доступ запрещен
GET /api/v1/admin/users (обычный пользователь)
Response: 403 Forbidden

Кэширование GET запросов

Поскольку GET запросы безопасны и idempotent, их можно кэшировать:

@GetMapping("/{id}")
@Cacheable(value = "products", key = "#id")
public ResponseEntity<ProductDto> getProduct(@PathVariable UUID id) {
    Product product = productService.findById(id);
    return ResponseEntity.ok(mapper.toResponse(product));
}

Мой подход в production

В реальных проектах я придерживаюсь этих правил для GET:

1. REST соглашения: существительные во множественном числе

   • ✅ GET /api/v1/users/{id}
   • ❌ GET /api/v1/getUser/{id}

2. Пагинация для больших наборов:

   • GET /api/v1/users?page=0&size=50

3. Фильтрация и сортировка:

   • GET /api/v1/users?status=active&sort=name,asc

4. Правильные коды ответов:

   • 200 OK для успеха
   • 404 Not Found для отсутствия
   • 400 Bad Request для ошибок валидации

5. Версионирование API:

   • /api/v1/users, /api/v2/users

6. Документация (Swagger/OpenAPI):

   @GetMapping("/{id}")
   @Operation(summary = "Get user by ID")
   @ApiResponse(responseCode = "200", description = "User found")
   @ApiResponse(responseCode = "404", description = "User not found")
   public ResponseEntity<UserDto> getUser(@PathVariable Long id) {
       // ...
   }
   

Итог: Для чтения сущности в CRUD-приложении используется HTTP GET метод, который должен быть безопасным, idempotent и возвращать правильные коды ответов.