Был ли ваш последний проект RESTful-сервисом?

Question

Был ли ваш последний проект RESTful-сервисом?

Тип вопроса: Архитектура Вероятность: 10% Категория: Java Разработчик

Ответ

Да, проект был RESTful-сервисом на Spring Boot, соответствующим ключевым принципам REST.

Реализованные принципы:

Единообразие интерфейса: Использование стандартных HTTP-методов.
- GET — получение ресурса.
- POST — создание.
- PUT — полное обновление.
- DELETE — удаление.
Статус-коды: Корректные HTTP-ответы (200 OK, 201 Created, 404 Not Found, 400 Bad Request).
Ресурсо-ориентированность: URL представляют сущности (например, /api/users).
Передача состояния (HATEOAS): В ответы включались ссылки на связанные действия.

Пример контроллера:

@RestController
@RequestMapping("/api/users")
public class UserController {

    @GetMapping("/{id}")
    public ResponseEntity<UserResponse> getUser(@PathVariable Long id) {
        UserResponse user = userService.findById(id);
        return ResponseEntity.ok(user); // 200 OK
    }

    @PostMapping
    public ResponseEntity<UserResponse> createUser(@Valid @RequestBody CreateUserRequest request) {
        UserResponse newUser = userService.create(request);
        URI location = ServletUriComponentsBuilder
                .fromCurrentRequest()
                .path("/{id}")
                .buildAndExpand(newUser.getId()).toUri();
        return ResponseEntity.created(location).body(newUser); // 201 Created
    }
}

Дополнительно:

Формат данных: JSON для запросов и ответов.
Аутентификация: JWT-токены, передаваемые в заголовке Authorization: Bearer <token>.
Документация: OpenAPI (Swagger) для описания API.

Ответ 18+ 🔞

А, ну это тот самый проект, где мы делали REST-сервис на Spring Boot. Ну, вроде как по всем канонам, блядь, чтобы не стыдно было показать. Всё по классике, без этих ваших выебонов.

Что там у нас по принципам было, ёпта:

Интерфейс единый, как мой взгляд на жизнь после пятницы. Использовали стандартные HTTP-методы, как учили.
- GET — чтобы получить что-то (ну, типа, дай сюда).
- POST — чтобы создать что-то новое (роди, блядь).
- PUT — чтобы всё обновить полностью, с корнем, вротберунчик.
- DELETE — чтобы удалить нахуй.
Статус-коды. Не просто так, а с чувством, с толком, с расстановкой. 200 — всё ок, 201 — родил, 404 — нихуя не нашёл, 400 — сам дурак, запрос кривой.
Всё через ресурсы. URL-ы у нас не какие-то левые, а прям вот /api/users, /api/cats — сразу понятно, с чем работаем.
HATEOAS, эта ваша хрень. В ответы засунули ссылки на связанные действия, чтобы клиент не гадал на кофейной гуще, куда топать дальше.

Вот, смотри, кусок контроллера, как оно выглядело:

@RestController
@RequestMapping("/api/users")
public class UserController {

    @GetMapping("/{id}")
    public ResponseEntity<UserResponse> getUser(@PathVariable Long id) {
        UserResponse user = userService.findById(id);
        return ResponseEntity.ok(user); // 200 OK
    }

    @PostMapping
    public ResponseEntity<UserResponse> createUser(@Valid @RequestBody CreateUserRequest request) {
        UserResponse newUser = userService.create(request);
        URI location = ServletUriComponentsBuilder
                .fromCurrentRequest()
                .path("/{id}")
                .buildAndExpand(newUser.getId()).toUri();
        return ResponseEntity.created(location).body(newUser); // 201 Created
    }
}

Ну и по мелочи, блядь:

Данные — JSON, туда-сюда. Никакого XML, нахуй.
Чтобы зайти — JWT-токен в заголовке Authorization: Bearer <token>. Без него — иди нахуй, незнакомец.
Документация — OpenAPI (Swagger), чтобы не пришлось каждому объяснять на пальцах, как этим пользоваться. Сам всё прочитает, если не дебил.