Я слышал о многих веб-API, таких как Facebook, Twitter и т. Д., Которые помогают третьим сторонам получать доступ к данным и манипулировать ими. Я хотел бы знать, как работает веб-API. Каковы основы веб-API?
Если я хочу создать API для своего сайта, чтобы люди могли получить к нему доступ или обновить его, с чего мне нужно начать?
web-development
web-applications
api
Хариш Куруп
источник
источник
Ответы:
В самом простом случае вы создаете набор запросов GET / POST, которые каждый может вызвать, и публикуете информацию об URL, параметрах и эффектах. GET-запросы для задач только для чтения и POST-запросы для всего, что изменит данные на сервере.
При необходимости добавьте систему аутентификации, и вы получите простой веб-API.
Web API является только интерфейсом , чтобы обеспечить доступ к системе (например, сайт) с помощью стандартных методов запроса HTTP . Сами данные обычно упаковываются в некоторый стандартный формат (например, JSON или XML ), чтобы их было легко обрабатывать.
Вот пример веб-API для «TextWise»
источник
Сейчас я разрабатываю API для платформы виртуализации моей компании. Вы можете использовать их несколькими различными способами, но мой любимый (и самый быстрый способ получить что-то работающее, понятное людям) - это использовать простые запросы HTTP GET и возвращать JSON-ответ.
Мой URL выглядит примерно так:
Затем я разбиваю переменные HTTP GET и делаю то, что хочет, чтобы вызывающий обращался с ними. Одна из главных причин, по которой я подписался как бета-пользователь на разработку Stack Exchange API, заключался в том, что я знал, что это будет огромный опыт обучения, и это действительно так .
Обычно я возвращаю два JSON-кодированных массива, один из
resultкоторых, по сути, просто говорит, был ли вызов успешным, и выдает код ошибки / строку ошибки, если нет. Другой обычно просто вызываетсяdata, и его содержание описано в документации этого конкретного вызова. Кроме того, API на основе GET намного проще тестировать и отлаживать.Существует множество других форматов, таких как SOAP / XMLRPC, я просто обнаружил, что выбор JSON дает мне невероятную простоту и свободу выбора.
Например, если мне нужно отправить много полей и я не хочу иметь дело с кучей переменных GET, я могу просто сделать это (пример в PHP)
Это легко декодируется с другой стороны, давая мне десятки переменных, с которыми можно работать, и в то же время принимающих только 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 в любом случае имеют тенденцию согласовывать формат, потому что было бы трудно разобраться во всех возможных форматах.
источник