Notice: This page requires JavaScript to function properly.
Please enable JavaScript in your browser settings or update your browser.Вивчайте Основні Принципи REST | RESTful Api
Spring Boot Backend

bookОсновні Принципи REST

Основні принципи REST становлять основу для створення ефективних та легко масштабованих веб-сервісів. У Spring Boot вони часто використовуються для реалізації API.

Розглянемо, що це за принципи, чому вони важливі, та проаналізуємо приклади їх застосування у Spring Boot.

Основні принципи REST

REST (Representational State Transfer) — це архітектурний стиль, заснований на шести ключових принципах, які допомагають розробникам створювати простi, гнучкі та масштабовані API. Ці принципи описують, як системи повинні взаємодіяти, щоб залишатися адаптивними та зручними для підтримки.

Архітектура клієнт-сервер

REST API має розділяти відповідальності між клієнтом і сервером. Клієнт відповідає за користувацький інтерфейс та відправлення запитів, тоді як сервер обробляє зберігання даних та обробку запитів.

REST API забезпечує чітке розмежування між клієнтською та серверною частинами застосунку, що дозволяє їм розвиватися незалежно.

Клієнтська частина може бути веб-браузером, мобільним додатком або будь-яким іншим клієнтським застосунком, а серверна частина може бути реалізована будь-якою мовою програмування.

Безстан

Кожен запит від клієнта до сервера повинен містити всю необхідну інформацію для обробки цього запиту. Сервер не повинен зберігати жодного стану між запитами, що гарантує ізольованість кожного запиту від інших.

Наприклад, уявімо, що у нас є застосунок, який повертає список продуктів різними мовами. Клієнт повинен включати інформацію про мову у кожен запит, щоб сервер знав, якою мовою відповідати. Сервер не зберігає інформацію про мову між запитами. Давайте реалізуємо цей приклад у коді.

Main.java

Main.java

copy

              
12345678910111213141516

            
@RestController
@RequestMapping("/products")
public class ProductController {

    @GetMapping
    public List<Product> getProducts(@RequestParam("lang") String language) {
        // Check the language requested by the client
        if ("en".equals(language)) {
            return productService.getProductsInEnglish();
        } else if ("es".equals(language)) {
            return productService.getProductsInSpanish();
        } else {
            return productService.getProductsInDefaultLanguage();
        }
    }
}

Цей код представляє REST-контролер, який обробляє HTTP GET запити на ендпоінті /products. Метод getProducts() приймає параметр lang, який вказує мову, якою клієнт бажає отримати дані.

Виходячи з цього параметра, метод повертає список продуктів на вказаній мові або на мові за замовчуванням.

Уніфікований інтерфейс

Щоб REST API було зручним у використанні, воно повинно мати просту та структуровану архітектуру. Це означає, що всі кінцеві точки мають дотримуватися певних базових принципів. Ось основні з них:

Використання іменників для представлення ресурсів замість дієслів. Наприклад, замість використання GET /createProduct, краще використовувати POST /products, де products — це ресурс.

GET /products — Отримання списку продуктів;

POST /products — Створення нового продукту;

PUT /products/{id} — Оновлення інформації про конкретний продукт, де {id} — це унікальний ідентифікатор продукту;

DELETE /products/{id} — Видалення продукту із заданим ідентифікатором.

Опис Spring REST контролера, який керує продуктами шляхом реалізації різних HTTP-методів для створення, отримання, оновлення та видалення даних продукту, дотримуючись найкращих практик для зручної структури API.

Main.java

Main.java

copy

              
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647

            
@RestController
@RequestMapping("/products")
public class ProductController {

    // Example of applying the client-server architecture principle
    private final ProductService productService;

    // Constructor injection ensures productService is provided by Spring
    public ProductController(ProductService productService) {
        this.productService = productService;
    }

    // Uniform interface principle: GET request to retrieve all products
    @GetMapping
    public List<Product> getAllProducts() {
        // Calls the service to return a list of all products
        return productService.getAllProducts();
    }

    // Uniform interface principle: POST request to create a new product
    @PostMapping
    public Product createProduct(@RequestBody Product product) {
        // Calls the service to create a new product based on the provided request body
        return productService.createProduct(product);
    }

    // Uniform interface principle: GET request to retrieve a product by its ID
    @GetMapping("/{id}")
    public Product getProductById(@PathVariable Long id) {
        // Calls the service to find and return the product with the given ID
        return productService.getProductById(id);
    }

    // Uniform interface principle: PUT request to update a product by its ID
    @PutMapping("/{id}")
    public Product updateProduct(@PathVariable Long id, @RequestBody Product product) {
        // Calls the service to update the product details based on the provided request body and ID
        return productService.updateProduct(id, product);
    }

    // Uniform interface principle: DELETE request to remove a product by its ID
    @DeleteMapping("/{id}")
    public void deleteProduct(@PathVariable Long id) {
        // Calls the service to delete the product with the specified ID
        productService.deleteProduct(id);
    }
}

Анотація @RequestMapping("/products") визначає, що базова URL-адреса /products буде автоматично додаватися до всіх маршрутів у цьому контролері.

У цьому прикладі контролер обробляє операції, пов’язані з сутністю Product (клас Product), тому базова URL-адреса — /products. Такий підхід дозволяє уникнути повторення /products для кожного методу. Натомість достатньо вказати HTTP-методи (GET, POST, PUT, DELETE), які будуть застосовані до цієї базової адреси.

GET /products — Отримання списку продуктів;

POST /products — Створення нового продукту.

Можна мати декілька кінцевих точок з однаковою URL-адресою, але різними HTTP-методами. Наприклад, GET /products та POST /products мають спільну URL-адресу, але використовують різні HTTP-методи. Клієнт вказує HTTP-метод у заголовку запиту, визначаючи, яку дію виконати.

Кешування

Для підвищення продуктивності сервер може вказати клієнту, коли кешувати дані. Це зменшує навантаження на сервер і прискорює обробку запитів.

Це означає, що коли метод викликається з однаковими параметрами, результат буде отримано з кешу, а не шляхом повторного виконання методу. Це може підвищити продуктивність за рахунок зменшення навантаження на сервіс.

У Spring Boot кешування відповідей можна керувати за допомогою анотацій або HTTP-заголовків. Ось приклад кешування даних:

Main.java

Main.java

copy

              
12345

            
@Cacheable("products")
@GetMapping
public List<Product> getAllProducts() {
    return productService.getAllProducts();
}

У цьому прикладі анотація @Cacheable використовується для кешування результату методу getAllProducts().

Анотація @Cacheable("products") вказує, що результат методу getAllProducts() буде збережено у кеші під іменем products. Коли метод буде викликаний знову з тими ж параметрами, Spring шукатиме результат у кеші products замість того, щоб виконувати метод повторно.

Багаторівнева система

Принцип багаторівневої системи у REST API означає, що клієнт не взаємодіє лише з одним сервером; натомість, він працює через кілька рівнів. Розглянемо це на прикладі трирівневої архітектури у Spring Boot.

Коли клієнт надсилає запит, він проходить через усі три рівні: від контролера до сервісу, потім до репозиторію і назад. Таке розділення допомагає підтримувати організованість системи та спрощує супровід коду.

Code on Demand

Хоча використовується рідше, REST API може повертати виконуваний код клієнту для виконання на їхній стороні. Цей принцип застосовується рідко та вимагає додаткових заходів безпеки.

Наприклад, API може повертати JavaScript-код, який виконується у браузері клієнта для обробки даних або виконання інших завдань. Це може бути корисно для динамічного завантаження функціоналу залежно від запитів, наприклад, для обробки форм або клієнтської валідації даних.

Підсумок

Основні принципи REST — це важливі орієнтири для створення гнучких та зручних у підтримці API. У Spring Boot ці принципи реалізуються за допомогою анотацій таких як @RestController, @Cacheable, які спрощують розробку структурованих та ефективних систем для взаємодії з клієнтами.

1. Який принцип REST дозволяє клієнту взаємодіяти з ресурсом за допомогою стандартних методів HTTP?

2. Що означає принцип відсутності стану (stateless) у REST?

question mark

Який принцип REST дозволяє клієнту взаємодіяти з ресурсом за допомогою стандартних методів HTTP?

Select the correct answer

question mark

Що означає принцип відсутності стану (stateless) у REST?

Select the correct answer

Все було зрозуміло?

Як ми можемо покращити це?

Дякуємо за ваш відгук!

Секція 3. Розділ 2

Запитати АІ

expand

Запитати АІ

ChatGPT

Запитайте про що завгодно або спробуйте одне із запропонованих запитань, щоб почати наш чат

Suggested prompts:

Can you explain each of the six REST principles in more detail?

How does Spring Boot help implement these REST principles?

Can you provide more examples of RESTful endpoints in Spring Boot?

Awesome!

Completion rate improved to 3.45

bookОсновні Принципи REST

Свайпніть щоб показати меню

Основні принципи REST становлять основу для створення ефективних та легко масштабованих веб-сервісів. У Spring Boot вони часто використовуються для реалізації API.

Розглянемо, що це за принципи, чому вони важливі, та проаналізуємо приклади їх застосування у Spring Boot.

Основні принципи REST

REST (Representational State Transfer) — це архітектурний стиль, заснований на шести ключових принципах, які допомагають розробникам створювати простi, гнучкі та масштабовані API. Ці принципи описують, як системи повинні взаємодіяти, щоб залишатися адаптивними та зручними для підтримки.

Архітектура клієнт-сервер

REST API має розділяти відповідальності між клієнтом і сервером. Клієнт відповідає за користувацький інтерфейс та відправлення запитів, тоді як сервер обробляє зберігання даних та обробку запитів.

REST API забезпечує чітке розмежування між клієнтською та серверною частинами застосунку, що дозволяє їм розвиватися незалежно.

Клієнтська частина може бути веб-браузером, мобільним додатком або будь-яким іншим клієнтським застосунком, а серверна частина може бути реалізована будь-якою мовою програмування.

Безстан

Кожен запит від клієнта до сервера повинен містити всю необхідну інформацію для обробки цього запиту. Сервер не повинен зберігати жодного стану між запитами, що гарантує ізольованість кожного запиту від інших.

Наприклад, уявімо, що у нас є застосунок, який повертає список продуктів різними мовами. Клієнт повинен включати інформацію про мову у кожен запит, щоб сервер знав, якою мовою відповідати. Сервер не зберігає інформацію про мову між запитами. Давайте реалізуємо цей приклад у коді.

Main.java

Main.java

copy

              
12345678910111213141516

            
@RestController
@RequestMapping("/products")
public class ProductController {

    @GetMapping
    public List<Product> getProducts(@RequestParam("lang") String language) {
        // Check the language requested by the client
        if ("en".equals(language)) {
            return productService.getProductsInEnglish();
        } else if ("es".equals(language)) {
            return productService.getProductsInSpanish();
        } else {
            return productService.getProductsInDefaultLanguage();
        }
    }
}

Цей код представляє REST-контролер, який обробляє HTTP GET запити на ендпоінті /products. Метод getProducts() приймає параметр lang, який вказує мову, якою клієнт бажає отримати дані.

Виходячи з цього параметра, метод повертає список продуктів на вказаній мові або на мові за замовчуванням.

Уніфікований інтерфейс

Щоб REST API було зручним у використанні, воно повинно мати просту та структуровану архітектуру. Це означає, що всі кінцеві точки мають дотримуватися певних базових принципів. Ось основні з них:

Використання іменників для представлення ресурсів замість дієслів. Наприклад, замість використання GET /createProduct, краще використовувати POST /products, де products — це ресурс.

GET /products — Отримання списку продуктів;

POST /products — Створення нового продукту;

PUT /products/{id} — Оновлення інформації про конкретний продукт, де {id} — це унікальний ідентифікатор продукту;

DELETE /products/{id} — Видалення продукту із заданим ідентифікатором.

Опис Spring REST контролера, який керує продуктами шляхом реалізації різних HTTP-методів для створення, отримання, оновлення та видалення даних продукту, дотримуючись найкращих практик для зручної структури API.

Main.java

Main.java

copy

              
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647

            
@RestController
@RequestMapping("/products")
public class ProductController {

    // Example of applying the client-server architecture principle
    private final ProductService productService;

    // Constructor injection ensures productService is provided by Spring
    public ProductController(ProductService productService) {
        this.productService = productService;
    }

    // Uniform interface principle: GET request to retrieve all products
    @GetMapping
    public List<Product> getAllProducts() {
        // Calls the service to return a list of all products
        return productService.getAllProducts();
    }

    // Uniform interface principle: POST request to create a new product
    @PostMapping
    public Product createProduct(@RequestBody Product product) {
        // Calls the service to create a new product based on the provided request body
        return productService.createProduct(product);
    }

    // Uniform interface principle: GET request to retrieve a product by its ID
    @GetMapping("/{id}")
    public Product getProductById(@PathVariable Long id) {
        // Calls the service to find and return the product with the given ID
        return productService.getProductById(id);
    }

    // Uniform interface principle: PUT request to update a product by its ID
    @PutMapping("/{id}")
    public Product updateProduct(@PathVariable Long id, @RequestBody Product product) {
        // Calls the service to update the product details based on the provided request body and ID
        return productService.updateProduct(id, product);
    }

    // Uniform interface principle: DELETE request to remove a product by its ID
    @DeleteMapping("/{id}")
    public void deleteProduct(@PathVariable Long id) {
        // Calls the service to delete the product with the specified ID
        productService.deleteProduct(id);
    }
}

Анотація @RequestMapping("/products") визначає, що базова URL-адреса /products буде автоматично додаватися до всіх маршрутів у цьому контролері.

У цьому прикладі контролер обробляє операції, пов’язані з сутністю Product (клас Product), тому базова URL-адреса — /products. Такий підхід дозволяє уникнути повторення /products для кожного методу. Натомість достатньо вказати HTTP-методи (GET, POST, PUT, DELETE), які будуть застосовані до цієї базової адреси.

GET /products — Отримання списку продуктів;

POST /products — Створення нового продукту.

Можна мати декілька кінцевих точок з однаковою URL-адресою, але різними HTTP-методами. Наприклад, GET /products та POST /products мають спільну URL-адресу, але використовують різні HTTP-методи. Клієнт вказує HTTP-метод у заголовку запиту, визначаючи, яку дію виконати.

Кешування

Для підвищення продуктивності сервер може вказати клієнту, коли кешувати дані. Це зменшує навантаження на сервер і прискорює обробку запитів.

Це означає, що коли метод викликається з однаковими параметрами, результат буде отримано з кешу, а не шляхом повторного виконання методу. Це може підвищити продуктивність за рахунок зменшення навантаження на сервіс.

У Spring Boot кешування відповідей можна керувати за допомогою анотацій або HTTP-заголовків. Ось приклад кешування даних:

Main.java

Main.java

copy

              
12345

            
@Cacheable("products")
@GetMapping
public List<Product> getAllProducts() {
    return productService.getAllProducts();
}

У цьому прикладі анотація @Cacheable використовується для кешування результату методу getAllProducts().

Анотація @Cacheable("products") вказує, що результат методу getAllProducts() буде збережено у кеші під іменем products. Коли метод буде викликаний знову з тими ж параметрами, Spring шукатиме результат у кеші products замість того, щоб виконувати метод повторно.

Багаторівнева система

Принцип багаторівневої системи у REST API означає, що клієнт не взаємодіє лише з одним сервером; натомість, він працює через кілька рівнів. Розглянемо це на прикладі трирівневої архітектури у Spring Boot.

Коли клієнт надсилає запит, він проходить через усі три рівні: від контролера до сервісу, потім до репозиторію і назад. Таке розділення допомагає підтримувати організованість системи та спрощує супровід коду.

Code on Demand

Хоча використовується рідше, REST API може повертати виконуваний код клієнту для виконання на їхній стороні. Цей принцип застосовується рідко та вимагає додаткових заходів безпеки.

Наприклад, API може повертати JavaScript-код, який виконується у браузері клієнта для обробки даних або виконання інших завдань. Це може бути корисно для динамічного завантаження функціоналу залежно від запитів, наприклад, для обробки форм або клієнтської валідації даних.

Підсумок

Основні принципи REST — це важливі орієнтири для створення гнучких та зручних у підтримці API. У Spring Boot ці принципи реалізуються за допомогою анотацій таких як @RestController, @Cacheable, які спрощують розробку структурованих та ефективних систем для взаємодії з клієнтами.

1. Який принцип REST дозволяє клієнту взаємодіяти з ресурсом за допомогою стандартних методів HTTP?

2. Що означає принцип відсутності стану (stateless) у REST?

question mark

Який принцип REST дозволяє клієнту взаємодіяти з ресурсом за допомогою стандартних методів HTTP?

Select the correct answer

question mark

Що означає принцип відсутності стану (stateless) у REST?

Select the correct answer

Все було зрозуміло?

Як ми можемо покращити це?

Дякуємо за ваш відгук!

Секція 3. Розділ 2
some-alt