Як працюють веб-API? [зачинено]

Я чув про багато веб-API, таких як Facebook, Twitter тощо, що допомагає сторонній стороні отримувати доступ до даних та маніпулювати ними. Я хотів би знати, як працює веб-API. Які основи веб-API?

Якщо я хочу створити API для свого сайту, щоб люди мали доступ до нього або оновили його, з чого мені потрібно почати?

Найпростіше, ви створюєте набір GET / POST запитів, на які кожен може зателефонувати та опублікувати інформацію про URL-адреси, параметри та ефекти. Отримати запити на завдання лише для читання та POST-запити на все, що змінить дані на сервері.

Якщо потрібно, додайте в систему аутентифікації, і у вас є простий веб-API.

Web API є тільки інтерфейсом , щоб забезпечити доступ до системи (наприклад, сайт) з допомогою стандартних методів запиту HTTP . Самі дані, як правило, загортаються в деякий стандартний формат (наприклад, JSON або XML ), щоб зробити їх легким в обробці.

Ось приклад веб-API для "TextWise"

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

Моя URL-адреса виглядає приблизно так:

domain.com/method/call/subcall?key=key&data=something

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

Зазвичай я повертаю два кодовані JSON масиви, один з яких є result, який в основному просто говорить, якщо виклик був успішним і надає код помилки / рядок помилки, якщо ні. Інший, як правило, просто викликається data, а зміст цього описується в документації цього конкретного виклику. Крім того, API на основі GET набагато простіше перевірити та налагодити.

Існує багато інших форматів, таких як SOAP / XMLRPC, я просто вважаю, що вибір JSON дає мені неймовірну простоту та свободу вибору.

Наприклад, якщо мені потрібно надіслати багато полів і не хочу мати справу з тонкою змінних GET, я можу просто зробити це (наприклад, в PHP)

$to_send = base64_encode(json_encode($some_array));

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

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

Це насправді дуже широке питання. У самому основному сенсі, веб-API працює, коли клієнт (наприклад, веб-браузер) робить запит HTTP якогось типу на веб-сервер. Сервер розглядає цей запит, щоб з'ясувати, що хоче користувач, а потім повертає дані у певному форматі (наприклад, на сторінці), який клієнт потім перевіряє, щоб отримати те, що він хоче. Мова йде лише про єдині речі спільного веб-API; Я усвідомлюю, що це насправді не відповідає вашому запитанню, але я хотів дати причину, чому питання настільки широке.

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

Віддалений виклик процедури (RPC)

В API стилю RPC зазвичай існує лише одна URL-адреса для всього API. Ви називаєте це, розміщуючи документ якогось типу, який містить інформацію про те, що ви хочете зробити, і сервер повертає документ, у якому є те, що ви хочете. У загальних обчислювальних термінах документ-запит зазвичай має ім'я функції та деякі аргументи.

Деякі стандарти цього стилю API включають XML-RPC та SOAP. Ці стандарти намагаються створити формат, який можна використовувати для опису викликів функцій, які ви здійснюєте, або навіть для опису всього API.

Представницький державний трансфер (REST)

У API стилю REST у вас не так багато URL-адреси для API, як простору імен : сервер або папка всередині сервера, де знаходиться багато різних об'єктів, і кожна URL-адреса в цьому просторі імен стає частиною API. Замість того , щоб говорити сервер , який ви хочете використовувати API, то URL повідомляє серверу , що ви хочете використовувати API на . Потім ви використовуєте метод HTTP та, можливо, орган запиту, щоб пояснити, що ви хочете зробити для цього об’єкта: GET (витягніть щось, що вже є), POST (створити щось нове), PUT (замініть те, що вже є) або ВІДКЛЮЧИТИ (позбутися від чогось, що вже є). Є кілька інших дієслів, якими ви можете скористатися, але це, безумовно, найбільш поширені.

Поки що я не згадував стандартних форматів для REST. Теоретично ви можете використовувати майже будь-який формат. HTTP вже передбачає, що потрібно сказати, що ви хочете зробити, і для чого ви хочете це зробити, тому формат тіла запиту може бути майже будь-яким: деяким поданням об’єкта, який ви хочете створити або замінити. Але на практиці автори REST, як правило, домовляються про формат, оскільки важко було б зрозуміти кожен можливий формат.