Основи REST і RESTful API Development

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

На цій посаді я хотів би пояснити RESTful практику розвитку з висоти пташиного польоту. Я хочу вирішити що а не як. Хоча я буду торкатися обох областей, ця публікація створена для тих, хто входить у веб-розробку, але просто не може зрозуміти концепцію API REST.

REST для веб-розробників

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

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

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

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

Що таке архітектура REST?

Тут важко скласти специфіку. Однак існують деякі архітектурні константи, такі як:

• Послідовність у всьому API
• Існування без громадянства, тобто відсутні сеанси на стороні сервера
• Використання Коди статусу HTTP у відповідних випадках
• Використання Кінцеві точки URL з логічною ієрархією
• Версія в URL замість заголовків HTTP

Не існує жодних занадто специфічних рекомендацій, таких як специфікація W3C HTML5, яка може призвести до плутанини, і міазму невизначеності щодо термінології REST..

Також наведений вище список не слід вважати жорсткими правилами, незважаючи на те, що вони стосуються самих сучасних RESTful API.

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

Як стверджує Віней Сагні, “API є інтерфейсом розробника.” Все має бути простим у використанні та забезпечити чудовий досвід користувачів. API RESTful прагнуть зробити це саме так.

Ключові висновки для API RESTful

Ці поради у контексті API строго для веб-додатків. Це означає що HTTP - це вимога, і це часто означає, що дані API розміщуються на зовнішньому сервері. Розглянемо, як RESTful APIs працюють на стороні користувача API.

Користувач API - це веб-розробник, який може створити скрипт, який підключається до зовнішнього API-сервера, після чого необхідні дані передаються через HTTP. Розробник може відобразити дані на своєму веб-сайті без особистого доступу до зовнішнього сервера (на зразок завантаження даних Twitter).

Взагалі є чотири команди звик до доступ до API RESTful:

1. GET для отримання об'єкта
2. POST для створення нового об'єкта
3. PUT для модифікації або заміни об'єкта
4. DELETE для видалення об'єкта

Кожен з цих методів повинен бути передано з викликом API сказати серверу, що робити.

Переважна більшість веб-API дозволяють тільки GET запитів витягнути дані з зовнішнього сервера. Перевірка автентичності є необов'язковою, але, звичайно, хороша ідея, коли дозволяють потенційно шкідливі команди PUT або DELETE.

Однак не багато RESTful API навіть йдуть так далеко. Подумайте про Pokéapi, яка є безкоштовною базою даних API Покемонів. Вона відкрита для громадськості з гідним обмеженням ставок (обмеження користувачів певним числом запитів API протягом певного періоду часу), але дозволяє лише GET метод доступу до ресурсів. Це можна розмовно називати a тільки для споживання.

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

Використовуються RESTful API іменники для об'єктів API, і дієслова для виконання дій на цих об'єктах. Аутентифікація може бути частиною цього, обмеження швидкості також може бути частиною цього. Але дуже простий API може обійтися без особливих проблем із обмеженнями користувачів.

Доступ до ресурсів API

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

Деякі URL-адреси можуть містити префіксний каталог / v2 / для оновленої версії 2 попереднього API. Це є звичайним для розробників, які не хочуть знецінювати свій API 1.x, але все одно хочуть запропонувати нову структуру.

Я дійсно отримав насолоду від цього пост покриття основні структури URL та приклади інших служб.

Зверніть увагу, що кінцеві точки дані повернення будуть змінюватися різко грунтується на Метод HTTP. Наприклад, GET отримує вміст, поки POST створює новий вміст. Запит може вказувати на ту ж кінцеву точку, але результат може бути дуже різним.

Розгляд прикладів в Інтернеті може допомогти вам зрозуміти поняття. Ми вже бачили Pokeapi, але ось деякі інші приклади реальних API проглядати:

• API Reddit
• GitHub API
• API Flickr
• Pinterest API

Створення власного API

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

Кожен API повинен підключитися до сервера повернути дані свого роду. Вам не тільки потрібно написати код, щоб зробити це, але також необхідно для форматування повернутих даних. Інші потенційні вимоги включають аутентифікації і обмеження швидкості, тому розробка API, звичайно, не для слабкодухих.

Але давайте подивимося деякі основні принципи архітектури API.

Збірка кінцевих точок

Одним з аспектів розвитку API є кінцеві точки будівлі. Коли створення ресурсів Ви хочете використовувати іменники, а не дієслова. Це означає, що дані API повинні повертати людину, місце або речі, найчастіше це річ зі специфічними атрибутами (наприклад, твіт і всі його метадані).

Це може бути важко навчитися називати іменники, але це важливий аспект розвитку API. Спрощення є найкращим, коли це можливо.

Велика дискусія однина чи множина іменники. Якщо ви робили API для Twitter, то спочатку можна мати групу об'єктів (наприклад, tweet), а потім другу позицію об'єкта (наприклад, tweet ID).

 $ / твіт / 15032934882934 $ / твітів / 15032934882934 

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

Встановіть тип повернення

Інший розгляд дані типу повернення. Більшість веб-користувачів очікують вмісту JSON, тому це, ймовірно, найкращий варіант. XML є іншим вибором, якщо ви хочете запропонувати обидва. Однак JSON є основним типом повернення API серед веб-розробників.

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

Якщо ви тільки починаєте роботу, будь ласка, подумайте про сканування цих навчальних посібників:

• Сайт навчального посібника REST API
• Написання простого REST API
• Створення веб-служби RESTful

Подальші ресурси

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

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

Якщо це ваша мета, будь ласка, розглянути наступні ресурси, щоб допомогти у дорозі.

Книги

• Правило розробки API REST
• Веб-API RESTful
• RESTful Кулінарна книга веб-служб
• Неспокійний REST: Керівництво по розробці ідеального API

Статті

• Посібник для початківців по HTTP і REST
• Створення API RESTful
• Посібник із іменування ресурсів RESTful
• Створення API REST за допомогою MEAN Stack