Как работают веб-API? [закрыто]

Я слышал о многих веб-API, таких как Facebook, Twitter и т. Д., Которые помогают третьим сторонам получать доступ к данным и манипулировать ими. Я хотел бы знать, как работает веб-API. Каковы основы веб-API?

Если я хочу создать API для своего сайта, чтобы люди могли получить к нему доступ или обновить его, с чего мне нужно начать?

В самом простом случае вы создаете набор запросов GET / POST, которые каждый может вызвать, и публикуете информацию об URL, параметрах и эффектах. GET-запросы для задач только для чтения и 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 и делаю то, что хочет, чтобы вызывающий обращался с ними. Одна из главных причин, по которой я подписался как бета-пользователь на разработку Stack Exchange API, заключался в том, что я знал, что это будет огромный опыт обучения, и это действительно так .

Обычно я возвращаю два JSON-кодированных массива, один из resultкоторых, по сути, просто говорит, был ли вызов успешным, и выдает код ошибки / строку ошибки, если нет. Другой обычно просто вызывается data, и его содержание описано в документации этого конкретного вызова. Кроме того, API на основе GET намного проще тестировать и отлаживать.

Существует множество других форматов, таких как SOAP / XMLRPC, я просто обнаружил, что выбор JSON дает мне невероятную простоту и свободу выбора.

Например, если мне нужно отправить много полей и я не хочу иметь дело с кучей переменных GET, я могу просто сделать это (пример в PHP)

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

Это легко декодируется с другой стороны, давая мне десятки переменных, с которыми можно работать, и в то же время принимающих только 2 - 3 переменных GET через API.

Я просто стараюсь сделать свои методы и вызовы короткими и лаконичными и спроектировать их так, чтобы каждый вызов возвращал единообразный ответ «сработал или не прошел», после чего следовали запрошенные данные.

На самом деле это очень широкий вопрос. В самом простом смысле веб-API работает, когда клиент (например, веб-браузер) отправляет HTTP-запрос на веб-сервер. Сервер проверяет этот запрос, чтобы выяснить, что хочет пользователь, и затем возвращает данные в каком-то формате (например, странице), который клиент затем проверяет, чтобы получить то, что он хочет. Это единственное, что общего у Web API; Я понимаю, что это на самом деле не отвечает на ваш вопрос, но я хотел бы объяснить, почему этот вопрос настолько широк.

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

Удаленный вызов процедур (RPC)

В API стиля RPC обычно есть только один URL для всего API. Вы вызываете это, отправляя документ какого-либо типа, который содержит информацию о том, что вы хотите сделать, и сервер возвращает документ, который имеет то, что вы хотите. В общих вычислительных терминах документ запроса обычно имеет имя функции и некоторые аргументы.

Некоторые стандарты для этого стиля API включают XML-RPC и SOAP. Эти стандарты пытаются создать формат, который можно использовать для описания вызовов функций, которые вы выполняете, или даже для описания всего API.

REpresentational State Transfer (REST)

В API стиля REST URL-адрес API-интерфейса у вас не так много, как пространство имен : сервер или папка внутри сервера, где находится множество различных объектов, и каждый URL-адрес в этом пространстве имен становится частью API. Вместо того , чтобы говорить сервер , который вы хотите использовать API, то URL сообщает серверу , что вы хотите использовать API на . Затем вы используете метод HTTP и, возможно, тело запроса, чтобы объяснить, что вы хотите сделать с этим объектом: GET (получить что-то, что уже есть), POST (создать что-то новое), PUT (заменить что-то, что уже есть) или УДАЛИТЬ (избавиться от чего-то, что уже есть). Есть несколько других глаголов, которые вы можете использовать, но они являются наиболее распространенными.

До сих пор я не упомянул стандартные форматы для REST. Теоретически, вы можете использовать практически любой формат. HTTP уже предоставляет возможность сказать, что вы хотите сделать и что вы хотите сделать, поэтому формат тела запроса может быть практически любым: некоторое представление объекта, который вы хотите создать или заменить. Но на практике авторы REST в любом случае имеют тенденцию согласовывать формат, потому что было бы трудно разобраться во всех возможных форматах.