Rest api для web сервісів

Rest api для web сервісів

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

Що ж таке REST?

Representational state transfer (передача стану управління) - це архітектурний стиль, який застосовується при розробці веб-сервісів, і встановлює 6 правил для їх побудови. Дотримуються цих правил веб-сервіси називають RESTful сервісами. Крім цього, REST також вимагає використання більшості можливостей протоколу http.

Отже, що ж це за правила?

  • Uniform Interface - єдиний інтерфейс
  • Stateless - відсутність станів
  • Cacheable - кешування
  • Client-Server - розмежована архітектура клієнт-сервер
  • Layered System - багаторівнева система
  • Code on Demand - код за запитом

Поговоримо про кожного з них більш детально.

єдиний інтерфейс

REST архітектура має на увазі визначення єдиного інтерфейсу взаємодії всіх клієнтів з сервером.

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

  • Формат для отримання колекції елементів: / buildings
  • Формат для отримання елемента по id: / buildings /

Інформація передається між клієнтами і сервером повинна бути конвертована в зручний для передачі формат. Прикладами таких форматів може бути JSON або XML, хоча все ж найбільш популярним на поточний момент є якраз JSON. Тим не менш, деякі веб-сервіси вміють підтримувати роботу з декількома форматами одночасно. В такому випадку формат повертаються даних сервером і формат даних, який сервер повинен обробити, управляється за допомогою HTTP заголовків Accept і Content-type. У заголовках можуть передаватися різні типи. Наприклад: application / json або application / xml.

відсутність станів

Кожен запит в RESTful-сервісі повинен унікально ідентифікувати себе ресурсом або ресурсами, і оперувати їх повними станами. REST веб-сервіси не повинні зберігати будь-які дані в сесіях запитів або cookies.

кешування

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

Клієнт-сервер

Інтерфейс, який реалізує взаємодію клієнтів і серверів, повинен явно розділяти обов'язки клієнтів і серверів і при цьому повинен бути реалізований незалежно від роботи будь-якого з них. наприклад:

  • клієнти не повинні мати уявлення про збереженої на сервері інформації, так як це зона відповідальності сервера.
  • Сервер не повинен бути розроблений в прив'язці до UI будь-якого клієнта.

Layered system

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

Code on demand

Чому саме REST?

Незважаючи на те, REST підходить для всіх проектів, що працюють по http, іноді його реалізація може бути неможлива в силу недостатніх навичок команди. Проте, якщо освоїти REST належним чином, перед розробниками відкривається безліч переваг:

  • Покращена продуктивність. REST повертає виключно дані, зазначені в запиті. Таким чином швидше обробляються запити і видаються відповіді.
  • Масштабованість. Додаток може працювати на безлічі серверів, що дозволяє балансувати навантаження між ними. Також сервіс можна розділити на кілька "мікросервісов", які зможуть працювати паралельно один одному.
  • Портіруемость завдяки єдиному інтерфейсу
  • Прозорість взаємодії - за рахунок своєї стандартизації API залишається зрозумілим для користувача.
  • Легкість змін. Завдяки меншій пов'язаності коду, знижується ймовірність "поламати" запити при внесенні змін в інші частини програми.

методи http

Http містить 4 методу: GET, POST, PUT, DELETE. Кожен метод має використовуватися для різних цілей і ідентифікувати функціонал, який запит реалізує.

  • GET. Використовується для отримання ресурсів (список ресурсів або один ресурс із зазначенням його id)
  • POST. використовується для створення ресурсів
  • PUT. Івикористовуються для відновлення ресурсів по id, який передається в URL
  • DELETE. Використовується для видалення ресурсів по id, який передається в URL

Нижче ми привели таблицю, содержащуя можливі запити для потенційного ресурсу people. У ній використані всі можливі http-методи і наведені відповіді, які ці запити можуть повертати.

Rest api для web сервісів

Http статус-коди

При використанні REST для веб-сервісів необхідно правильно підібрати http статуси для соответсвуюшіх відповідей сервера. Сам по собі http має кілька десятків статус-кодів, але ми наведемо 10 найбільш часто використовуваних:

Http статус-коди мають велику кількість кодів для обробок помилок, але цих кодів мало для будь-якої програми. У подібних випадках в тіло відповіді можна включити повідомлення, що розкриває суть помилки більш докладно (використовуючи json, xml і т.д.). Клієнти, які вже знають про отриманий код, зможуть коректно його обробити.

додатково

  • Запити, які повертають колекції елементів, повинні мати можливість пагінацію, сортування, фільтрації
  • Дати і час в запитах слід передавати в форматі unix timestamp в мілісекундах.
  • Версія додатка повинна бути зашита в URL додатки як node. Наприклад: api.app.com/v1/buildings

Якщо у вас залишилися які-небудь питання, ви можете зв'язатися з нами для отримання професійної технічної консультації. Ми будемо раді допомогти вам з реалізацією будь-яких ваших ідей!

Схожі статті