Rest api, rest додатки що це і з чим його їдять (full) - stack overflow російською

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

Ви, напевно, вже зустрічали розшифровку Representational State Transfer. Якщо зовсім грубо, то це явна передача стану додатка за допомогою HTTP (звучить кострубато, так? Зробимо вигляд, що цієї пропозиції взагалі не було). У загальному і цілому це просто концепція оформлення інтерфейсу для клієнтів API.

Незважаючи на те, що така штука може працювати, автоматизуватися вона не буде взагалі. Яка операція йде назовні - на читання, оновлення, створення або видалення? Чи можна її повторювати? До якого ресурсу вона відноситься? Чи можна легко локалізувати доменну область помилки в разі її виникнення? На всі питання можна відповісти негативно, навіть на ті, які не мають на увазі булевого відповіді; це - API нульового рівня REST, або API, яке з REST взагалі ніяк не пов'язано.

Однак цей приклад висмоктаний з пальця. Куди частіше все-таки по URL можна визначити, з чим ведеться робота, наприклад, той же вконтактік з його audio.get дає можливість визначити, що клієнт буде отримувати саме дані про аудіо. Це перший рівень зрілості REST - розбиття API на окремі ресурси, з якими ведеться робота. Тільки зазвичай, звичайно, ресурси розбиваються іншим чином:

• / Audio - колекція аудіозаписів
• / Audio / 1234 - окремий ресурс аудіозаписи з ідентифікатором +1234

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

В контексті прикладу з магазином запити вже можуть виглядати ось так:

І, нарешті, є третій рівень зрілості REST, але він (ще) практично ніде не використовується. На цьому рівні API віддає не тільки ресурси, але і підказки по управлінню цими ресурсами. Якщо уявити наступний лістинг:

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

Ну так от, що таке REST? REST - це парадигма організації API, яка має на увазі (крім іншого) чітке розбиття на ресурси і виклик операції за допомогою конкретного HTTP-методу. Але - тільки в межах цієї розповіді і перетолков суто вебдевелоперского характеру: строго кажучи, REST - це більш строгий набір вимог. з якого і відбувається необхідність працювати таким чином. Але коли ви бачите в інтернеті "REST API" - це про чіткий поділ на ресурси, про операції через HTTP-методи, про правильний Content-Type в залежності від Accept, про вираз помилок через коди HTTP і единообразность подання цих ресурсів. А суфікс (який насправді ful, а не full) означає тільки перетворення слова в прикметник, REST - парадигма, RESTful API - API, відповідний парадигмі.

Що вона взагалі дає? По-перше, API стає свіжим і приємно пахне - з ним легко і просто працювати, тому що ви знаєте, що від нього очікувати, що ресурси завжди будуть представлені в одному і тому ж вигляді, і знаєте це не тільки ви, але і будь-який API-клієнт (і, більш того, можна спорудити api-клієнт, не знаючи кінцевих ресурсів); по-друге, ця логіка відноситься не тільки до конкретного API, але і до всіх API, побудованим по парадигмі REST. Тому одного разу освоївшись з API github освоїтися з будь-яким іншим REST API не складе ніяких труднощів.

На той випадок, якщо я став писати дуже узагальнено і гуманітарно - додаткові посилання: