Работая с API, можно испытывать одновременно радость и разочарование. С одной стороны, взаимодействуя с другими приложениями, вы можете сильно увеличить охват аудитории и "вау-эффект" вашего приложения. С другой, это включает в себя чтения тонны документации, изучение стратегий аутентификации и разбор неинформативных (или даже отсутствующих) сообщений об ошибках.

Прежде всего, если вы до сих пор не до конца понимаете, что же такое API (Application Programming Interface - интерфейс программирования приложений), прочтите объяснение от Skillcrush , а затем первую часть этой статьи , чтоб наверстать упущенное.

"API" невероятно обширная концепция - каждый раз, когда ваше приложение "общается" с другим приложением, это происходит через некий API. Компоненты внутри вашего собственного приложения, вроде разных частей Rails, также общаются друг с другом через API. Они являются более или менее независимыми субприложениями, которые передают данные, необходимые каждому из них для выполнения собственных специфических задач. В мире приложений все является API!

Когда вы создаете приложения с более динамической фронтенд-функциональностью (как одностраничные Javascript-приложения, так и простые приложения с отдельными AJAX-вызовами), они будут общаться с Rails-бэкендом через ваш собственный API, который в действительности просто дополнительная пара-тройка строк кода, говорящая вашим контроллерам, как отдать JSON или XML вместо HTML.

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

Пункты для размышления

Просмотрите вопросы и проверьте, знаете ли на них ответы. Проверьте себя снова после выполнения задания.

  • Как Rails понимает, какой тип файла вы ожидаете в ответ, когда посылаете HTTP-запрос.
  • В чем заключается цель метода #respond_to ?
  • Как вернуть объект пользователя (User), при этом указать атрибуты, которые не хотите включать в этот объект (то есть, вы не можете просто вернуть User.first)?
  • Назовите 2 шага, выполняемых "за кулисами" метода #to_json .
  • Как указать действию контроллера, что требуется рендерить лишь сообщение об ошибке?
  • Как создать свое собственное сообщение об ошибке?
  • Почему вы не можете использовать методы аутентификации контроллера, основанные на сессиях, если хотите позволить программно подключаться к вашему API?
  • Что такое "Сервис-ориентированная архитектура"?

Основы API

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

Однако, часто вы хотите сделать запрос, который не требует переживать все головные боли от использования браузера. Вас может не заботить структура страницы (HTML), но взамен вы хотите получить чистые данные. Допустим, вы хотите получить список всех пользователей. Вы можете запросить что-то вроде http://yourapplication.com/users , что наверняка запустит действие #index и отрендерит список всех пользователей приложения.

Но зачем заморачиваться со всей этой лишней информацией, если все чего вы хотите - это получить список пользователей? Самым простым вариантом будет отправить запрос на тот же самый URL, указав ожидание JSON или XML ответа взамен. Если вы правильно настроите ваш Rails-контроллер, назад вы получите простой JSON объект-массив, содержащий всех пользователей. Прекрасно!

Тот же самый принцип применяется, когда вы общаетесь с внешним API. Скажем, вы хотите получить недавние "твиты" пользователя из Twitter. Вам потребуется лишь сообщить вашему Rails-приложению как взаимодействовать с API Twitter"а (т.е. аутентифицировать себя), отправить запрос и обработать набор "твитов", который будет возвращен.

Создание API

Вы можете захотеть сделать ваше Rails-приложение чистым бэкенд API для фронтенд веб-страниц, или просто захотите научиться посылать JSON, когда фронтенд запрашивает его. Этот раздел не осветит как создавать полноценные RESTful API с функциями аутентификации. Это плавное введение в обращение с вашим приложением как с API.

Основы

Если вы хотите, чтобы ваше Rails-приложение возвращало JSON вместо HTML, вам потребуется сказать вашему контроллеру, чтобы он это делал. Самое замечательное то, что одно и то же действие контроллера может возвращать различные типы в зависимости от того, делает ли ваш пользователь обычный запрос из браузера или обращается к API через командную строку. Это определяет какой тип запроса был сделан, основываясь на расширении запрашиваемого файла, например, example.xml или example.json .

Вы можете проверить, что Rails "думает" об ожидаемом вами типе файла, проверив серверный лог:

Started GET "/posts/new" for 127.0.0.1 at 2013-12-02 15:21:08 -0800 Processing by PostsController#new as HTML

Первая строка говорит вам какой URL был запрошен, а вторая сообщает куда он был направлен и как Rails его обрабатывает. Если бы вы использовали расширение.json , то это выглядело бы так:

Started GET "/posts.json" for 127.0.0.1 at 2013-12-04 12:02:01 -0800 Processing by PostsController#index as JSON

Если у вас есть запущенное тестовое приложение, попробуйте запросить различные URL. Если ваш контроллер не умеет их обрабатывать, то вы можете получить ошибку, но все равно должны видеть, что Rails понимает под вашими запросами.

Рендеринг JSON или XML

Когда вы решите, что хотите отвечать на запросы с помощью JSON или XML, вам потребуется сообщить вашему контроллеру, что нужно рендерить JSON или XML вместо HTML. Один из способов сделать это - использовать метод #respond_to:

Class UsersController < ApplicationController def index @users = User.all respond_to do |format| format.html # index.html.erb format.xml { render xml: @users } format.json { render json: @users } end end end

В данном случае, #respond_to передает в блок объект формата, к которому вы можете приложить соответствующий вызов рендеринга. Если вы ничего не сделаете, будет рендериться html с использованием стандартного Rails-шаблона (в этом примере app/views/index.html.erb).

Функция #render достаточно умна, чтобы понять, как рендерить широкий спектр форматов. Когда вы передаете ей ключ:json , она вызовет #to_json на значении, в данном примере на @users . Это преобразует ваш(и) Ruby-объект(ы) в JSON-строки, которые будут переданы запрашивающему приложению.

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

Указание возвращаемых атрибутов

Допустим, вы хотите убедиться, что не возвращаете email-адрес пользователя вместе с объектом пользователя (User). В этом случае, вы захотите изменить атрибуты, которые будут возвращаться, модифицируя то, что делает метод #to_json .

Раньше вы бы просто переопределили метод #to_json своей версией, но теперь вам это не понадобится - в действительности, вы взамен переопределите метод #as_json . Метод #as_json используется в методе #to_json , так что его модификация неявно изменён результат #to_json , но довольно специфическим способом.

#to_json делает 2 вещи: запускает #as_json и получает хэш атрибутов, которые будут отрендерены в JSON. Затем он проводит рендеринг в JSON, используя ActiveSupport::json.encode . Так что, модифицируя #as_json , вы более конкретно указываете ту часть метода #to_json , которую в действительности хотите изменить.

В нашем случае, мы делаем это модифицируя #as_json в нашей модели так, чтобы возвращать лишь необходимые нам атрибуты:

# app/models/user.rb class User < ActiveRecord::Base # Вариант 1: Полное переопределение метода #as_json def as_json(options={}) { :name => self.name } # НЕ включаем поле email end # Вариант 2: Используем стандартный метод #as_json def as_json(options={}) super(only: [:name]) end end

Затем, в нашем контроллере лишь потребуется отрендерить JSON как обычно (в примере ниже всегда будет возвращаться JSON, независимо от того, был ли отправлен HTML-запрос или нет):

# app/controllers/users_controller.rb class UsersController < ApplicationController def index render json: User.all end end

Заметьте, что вам не нужно самостоятельно вызывать #to_json , когда вы используете #render - он сделает это за вас.

Иногда Heroku может потребовать дополнительные шаги для корректного отображения ваших страниц с ошибками. Посмотрите . Вам может потребоваться сперва удалить статичные страницы из директории app/public .

Обеспечение безопасности извне

Допустим, вы хотите позволить обращаться к API только если пользователь залогинен. Ваша существующая аутентификация в контроллере уже делает эту работу - просто убедитесь, что у вас установлен правильный #before_action (например, before_action:require_login). Может потребоваться функционал, когда и залогиненный и не залогиненный пользователи могут просматривать страницу, но каждый должен видеть различные данные. Вы не хотите, чтобы незалогиненные пользователи имели возможность делать запросы к API для получения важных данных. Аналогично, вы не хотите давать возможность посещать определенные HTML-страницы неавторизованным пользователям.

Если вы хотите обрабатывать запросы из приложения, которое не является браузером (например, из командной строки), вы не можете полагаться на браузерные "куки" для аутентификации. Вот почему большинство API использует собственные токены как часть процесса аутентификации. Мы поговорим чуть больше о токенах в следующем уроке.

Следующие шаги

Теперь у вас есть навыки использования вашего Rails-приложения для отдачи не только HTML, но и любого другого формата. Если вы хотите пойти дальше и позволить другим разработчикам создавать что-то с использованием вашей платформы (например, чтобы они могли делать программные запросы вместо аутентификации в качестве пользователя), вам понадобится сделать вашу API-систему намного более надежной. Мы не будем освещать все это здесь, но посмотрите следующие материалы:

  • Статья Building Awesome Rails APIs содержит описание множества лучших подходов для движения от игрушечного приложения в сторону стандартов промышленных API.

Сервис-ориентированная архитектура

Пришло время представить архитектурный подход под именем "Сервис-ориентированная архитектура" (Service-Oriented Architecture, SOA). Основная идея заключается в том, что ваше приложение будет состоять из множества сервисов, вроде системы оплаты, регистрации пользователей, модуля рекомендаций и т.д. Вместо того, чтобы создавать все это внутри одного главного приложения, вы разбиваете подсистемы на полностью независимые кусочки, которые взаимодействуют друг с другом, используя внутренние API-интерфейсы.

Это хорошо по многим причинам. Благодаря тому, что каждый кусочек вашего приложения не заботится о том, как работают другие части, и знает только как запросить данные через их API, вы можете делать значительные изменения в коде сервиса, и все остальное приложение будет работать, как и прежде. Вы можете полностью заменить один сервис на другой, и, пока он взаимодействует, используя те же API-методы, это пройдет очень гладко. Вы можете использовать внешние API как часть вашего приложения (например, платежные системы) вместо написания собственного. Вы можете создать PHP-приложение, взаимодействующее с Python-приложением, взаимодействующим с Rails-приложением, и все будет работать, ведь они общаются между собой с помощью API.

Как правило, стараться делать максимально независимой каждую часть вашего приложения - хорошая идея. Концепция СОА подталкивает вас мыслить в рамках того, какие именно методы вы хотите предоставлять другим частям вашего приложения, и заодно это сделает ваш код лучше. Вдобавок, предполагая, что каждый крупный компонент вашего приложения независим, вы также сможете намного легче выделять проблемы и обрабатывать ошибки более осмысленно.

Использовать сервис-ориентированную архитектуру для целого приложения - это что-то вроде разбиения гигантского сложного Ruby-скрипта на изящные классы и методы, только в большем масштабе.

Одним из наиболее известных случаев перехода на сервис-ориентированную архитектуру является Amazon.com. Однажды в 2002 году, Джефф Безос прямо заявил, что все рабочие группы должны перейти на СОА, или будут уволены. Печально известный пост из блога сотрудника Google, предназначенный внутрикорпоративных целей, но случайно ставший открытым для публики, рассказывал о мощи Amazon с использованием СОА. Это отличное чтиво, так что обязательно его оцените, но основные тезисы письма Безоса вынесены в следующие цитаты из поста:

1) Все команды отныне предоставляют свои данные и функциональность через интерфейсы сервисов.

2) Команды должны взаимодействовать друг с другом посредством этих интерфейсов.

3) Иные формы межпроцессного взаимодействия запрещены: никаких прямых ссылок, никакого непосредственного чтения данных другой команды, никаких моделей общей памяти, никаких "бэкдоров" и тому подобного. Единственный разрешенный способ взаимодействия - обращение к интерфейсу сервисов через сеть.

4) Неважно какую технологию они используют. HTTP, Corba, Pubsub, собственные протоколы - без разницы. Безоса это не волнует.

5) Все интерфейсы сервисов, без исключения, должны быть изначально спроектированы с возможностью управления извне. То есть, команда должна планировать и проектировать так, чтобы быть в состоянии предоставить интерфейс разработчикам вне компании. Никаких исключений.

6) Любой проигнорировавший эти требования будет уволен.

СОА - это серьезное дело. Несомненно, есть много проблем, которые всплывают при ее использовании - посмотрите этот пост о "извлеченных уроках" Amazon - но она имеет невероятно много преимуществ.

Вы, наверняка, не будете сильно беспокоиться о СОА, пока создаете "игрушечные" приложения для самих себя, но этот вопрос определенно встанет перед вами, когда вы начнете работать на ИТ компанию, поэтому знакомство с ней - это хорошая практика.

Ваша цель

  1. Прочитайте раздел 7 руководства Rails по контроллерам , чтобы изучить рендеринг JSON и XML.
  2. Они не обязательны к просмотру (потому что они идут немного дальше, чем мы сейчас подготовлены), но, если вам интересно, взгляните на Railscasts в разделе Дополнительных ресурсов внизу урока, чтобы больше узнать о преимуществах API.

Заключение

Мы плотнее поработаем с вашим приложением как с API во время курса по Javascript. В этом курсе вы создадите несколько полноценных (фулл-стэк) приложений, использующих AJAX-вызовы для лучшего пользовательского интерфейса, что по факту включает в себя рендеринг XML или JSON данных взамен полноценной HTML-страницы. Затем вы создадите несколько одностраничных Javascript-приложений, которые полагаются на API, предоставляемом вашим Rails-приложением, для получения всех необходимых данных из БД, а во всем остальном работающих на стороне клиента (в браузере).

Лучший способ разобраться с API - создать и взаимодействовать с ним, на чем мы сфокусируемся в наших проектах.

Для того, чтобы облегчить труд своих коллег и обеспечить всем программам для Windows универсальный интерфейс, программисты Microsoft создали такую вещь, как API - "Application Programming Interface".

Это - набор функций и процедур, которые могут наиболее часто использоваться программами: отображение дерева каталогов, поиск файлов, отображение стандартного окна с кнопками закрытия, минимизации и развертывания на весь экран и многих других. В итоге разработчик, создающий программу для Windows, не должен продумывать и разрабатывать специальные подпрограммы для отображения окна программы, окна для выбора папки и остальных подобных элементарных операций, - ему достаточно просто вызвать из библиотек kernel32.dll или user32.dll, содержащих функции и процедуры API, нужную ему функцию, а она уже все сделает за него сама. Таких функций и процедур много - порядка 600.

В операционной системе MS-DOS такого понятия, как API, не было, - тот, кто брался писать программу для этой операционной системы, обязан был сам, от начала до конца, продумать и реализовать способы выдачи на экран изображения, получения данных от пользователя, путешествия по файловой системе, рисования графики, если таковая возможность была необходимой 2 . Это делало процесс разработки программ с удобным для пользователя интерфейсом весьма трудоемким процессом, зачастую затраты времени и сил на создание приемлемого графического интерфейса программы превосходили затраты на реализацию собственного алгоритма программы, ради которого она и создавалась. Недаром были очень распространены так называемые "консольные" приложения, то есть программы, работающие только из командной строки, без интерфейса, - ввод данных происходил в той же командной строке или производился из указанного в ней файла, а вывод результатов шел в простом текстовом режиме.

С появлением операционной системы Windows каторжный труд программистов по разработке внешнего вида программы и удобных способов ввода и вывода информации резко облегчился, - уже в Windows 3.0 использовались функции API. Теперь программист, если он, например, желал создать окно ввода текста или полосу прокрутки, должен был всего лишь написать вызов функции отображения такого окна с необходимыми ему параметрами, так же, как и любой другой функции языка, на котором он писал свою программу, а не вводить огромные обьемы кода ради создания программы, заново рисующей такое окно или полосу (сознавая при этом, что при разработке следующей программы, в которой тоже будут использоваться такие объекты, ему придется вновь разрабатывать такой код или пытаться частично использовать старый, приспосабливая его к нуждам этой новой программы). Поэтому появление API совершило революционный прорыв в технологии программирования, позволяя создавать нужные программы с привычным удобным интерфейсом гораздо быстрее, не заботясь о таких рутинных деталях, как программирование стандартных объектов интерфейса для ввода и вывода информации.

В языке Visual Basic for Applications (VBA) многие функции и процедуры API вызываются сами при выполнении программы интерпретатором, так что использовать их для отображения окон ввода и вывода текста, рисования на экране геометрических фигур и других простых действий совершенно нет необходимости, - их VBA вызывает по мере надобности, а программе на нем достаточно использовать соответствующие функции этого языка. Однако иногда возникает необходимость в некоторых действиях, для которых либо нет аналогов во встроенных функциях VBA, либо они работают нерационально или слишком медленно. Например, окно выбора папки с изображением дерева каталогов (рис.5.1) или программа поиска файлов (аналог на функциях VBA - объект "Application.FileSearch" - работает слишком медленно при больших количествах файлов). Для таких случаев в VBA предусмотрена возможность вызова функций API.

К сожалению, использование функций API в VBA не документировано в справке, вследствие чего для изучения способов их применения приходится либо искать книги или источники в Интернете по офисному программированию, либо анализировать код программ, в которых имеются вызовы функций API.

В подавляющем большинстве случаев при программировании для Office можно обойтись без использования API, но иногда только вызов API-функции может привести к достижению нужного результата. Скажем, вам надо обеспечить вызов разных макросов при простом нажатии мышью кнопки на какой-либо панели инструментов Word и в случае одновременного нажатия этой кнопки и клавиши Shift или Control. Вот фрагмент кода, делающего это:

Declare Function GetAsyncKeyState Lib "user32.dll" (ByVal kState As Long) As Integer

GetAsyncKeyState (vbKeyShift Or vbKeyControl)

If GetAsyncKeyState(vbKeyShift) Then

Call macro1: Exit Sub

ElseIf GetAsyncKeyState(vbKeyControl) Then

Call macro2: Exit Sub

Первая строчка - это как бы "резервирование" функции API для использования в программе на VBA. Видно, что вызывается функция GetAsyncKeyState из библиотеки (файла, содержащего программы, предназначенные только для использования другими программами) user32.dll, причем в эту функцию передается номер клавиши, а возвращает она целое число (а именно - 0, если клавиша с соответствующим номером не нажата, и -32767 или 1, если нажата). Любую функцию или процедуру, вызываемую из библиотек, не относящихся к VBA, необходимо так резервировать с помощью команды Declare.

Фраза vbKeyShift в команде - это заменитель кода клавиши Shift (его значение - 16), а vbKeyControl, как нетрудно понять - заменитель кода клавиши Control. Структура инструкций "If…Then", думается, ясна 3 , а если нет - посмотрите в справке VBA. Команда Call перед именем макроса, как вы помните, означает его запуск.

В Интернете есть русские сайты, посвященные API 4 . Посетите их, чтобы узнать больше об этом наборе функций.

У вас есть собака. Но она не разговаривает на человеческом языке. Однако она способна "понимать" его путём команд, которым её научили в процессе дрессировки. Если сказать пёсику, знающему команду "тапки!" что-то типа "Рексик, принеси мне, пжалста, тапули мои с зайчушками", он разве что на кличку ухом поведёт, но тапки не принесёт. Так вот, API - это набор команд, с помощью которых ваш пёсик вас понимает и делает то, что вам нужно. Это очень сильно упрощённо и для чайника, но суть понятна, думаю.

API это язык, регламентированный способ, общения одной компьютерной программы с другой для совместного исполнения какой-нибудь общей задачи, когда одна программа выполняют запросы другой. Application Programming Interface (API) - Интерфейс программирования приложений.

Вот какая примитивная аналогия для чайников родилась навскидку.

Представьте себе 5 иностранцев, разговаривающих на разных языках, которым нужно работать и жить вместе, скажем в России. Ни один из них не знает языка другого, при этом им нужно единой командой, по ролям, выполнить какую-то задачу, например накормить друг друга и обсудить вкус еды на русском языке. Для этого необходимо купить продукты, приготовить еду, накрыть на стол и за едой обсудить блюда. Чтобы они поняли друг друга и смогли найти продукты во внешнем мире, обучим их базовому набору русских слов. Представим что у нас есть:

1. Француз

2. Испанец

4. Англичанин

5. Итальянец

Распределим между ними роли для выполнения подзадач следующим образом

Покупка Еды: Француз и Испанец

Готовка Блюд: Испанец, Немец и Англичанин

Cервировка Стола: Англичанин и Итальянец

Трапеза и обсуждение вкуса Блюд: ВСЕ

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

Так вот. Группа наших иностранных друзей это группа компьютерных программ , которым нужно общаться между собой и со внешней средой.

Язык и Cлова, обозначающие продукты и элементарные действия , которые нужно произвести это API – стандарты по которым наши иностранные друзья общаются между собой на русском, чтобы выполнить все поставленные подзадачи.

API 1: Слова обозначающие Продукты и Где Купить
API 2: Слова обозначающие Блюда и Способы приготовления
API 3: Слова обозначающие Приборы и Действия с ними
API 4: Слова обозначающие Вкус и Оценку Еду

Может быть и сложнее, например, пусть API 2 это будет турецкий язык, API 3 это китайский язык, API 4 это хинди

Пример для чайников:

1. Есть розетка. За ней огромное количество техники скрывается. Но что бы ей пользоваться - надо иметь вилку с расстоянием между стержнями 3см и розетка отдаст 220в. Это и есть API интерфейс огромной системы электропроизводства.

2. А есть утюг. У него своя сложная система работы. Но что бы работать с розеткой, он соблюдает требования API - нужна вилка с расстоянием 3см и в ответ ждет 220вольт.

И всё. 2 системы независимы, они огромны и сложны. Но API делается, что бы максимально просто соединиться друг с другом.

API - application programming interface. Это некий набор функций, констант, классов и, возможно, других объектов, для взаимодействия с неким куском программы.

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

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

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

API (application programming interface ) - это интерфейс прикладного программирования . Если говорить более простым языком, то это набор различных функций, констант, классов, форматов запросов, которые можно использовать в других программах.

Можно считать, что API - это некий объект, реализацию которого мы не знаем, однако, можем его использовать. Например, компьютер - объект, реализацию которого знают очень мало людей, однако, использовать его могут почти все, совершая какие-то действия: просмотр видео, сёрфинг по Интернету, печать текста и прочее. Как это всё работает - мало, кто знает, а вот делать это могут чуть ли не все.

Примером API является Windows API , OpenGL API , Direct3D API и так далее.

Например, не так давно я тоже столкнулся напрямую с API . Я зарегистрировался на сервисе почтовых рассылок "SmartResponder.ru " и завёл рассылку, на которую стали подписываться люди. Задача была следующая: в течение суток после подписки человек может приобрести со скидкой мой платный видеокурс. Так как вся информация о подписчиках хранится на сервере "SmartResponder.ru ", то обычный доступ (например, через БД ) к этим данным я не имел, а реализовывать это было нужно. Благо, у "SmartResponder.ru " есть свой собственный API , которым я и воспользовался.

Я нашёл в их API формат запроса, чтобы в результате вытащить дату подписки. Далее через cURL я отправил соответствующий запрос и получил искомую дату подписки для конкретного e-mail адреса . Далее стандартная обработка и вывод результата.

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

При работе через API приложение отправляет запрос к сервису и получает ответ, содержащий запрошенные данные, вне зависимости от того, на каком языке программирования они созданы.

Что позволяет делать API платформы beseller?

Цель создания API платформы beseller - предоставление сторонним приложениям возможности взаимодействия с сайтами и базами данных интернет-магазинов.

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

Владельцы интернет-магазинов при помощи сторонних сервисов и собственных приложений имеют возможность обращаться по API к:

Информации об оформленных заказах

Доступные действия (методы) обработки информации о заказах:

  1. Выбор информации о заказе по ID
  2. Выбор информации о заказах по фильтру
  3. Количество заказов по фильтру
  4. Создание заказа
  5. Удаление заказа
  6. Массовое удаление заказов
  7. Выбор всех доступных статусов для заказов
  8. Обновление статуса заказа
  9. Добавление комментария к заказу

Информации о подписчиках

  1. Добавление подписчика
  2. Удаление подписчика
  3. Массовое удаление подписчиков
  4. Выбор данных о подписчиках по фильтру
  5. Количество подписчиков по фильтру

Информации о зарегистрированных пользователях

Доступные действия (методы) обработки информации о подписчиках:

  1. Выбор информации о зарегистрированных пользователях по ID
  2. Выбор информации обо всех зарегистрированных пользователях
  3. Выбор информации обо всех данных указанных пользователем при регистрации:

Обратите внимание! При регистрации, пользователь может не заполнить все указанные выше поля.

Планы по развитию API

В ближайшее время, мы планируем открыть интерфейсы для поддержки взаимодействия магазинов со сторонними приложениями и сервисами по работе с:

  1. Разделами каталога.
  2. Товарами.
  3. Корзиной.
  4. Скидками.
  5. Способами доставки.
  6. Способами оплаты.

Для тестирования взаимодействия с API платформы beseller создан тестовый магазин beseller-api.shop.by .

Для доступа к тестовому магазину необходимо указать логин и пароль. Их вы можете получить по запросу у вашего персонального менеджера.

Перед тестированием взаимодействия с API мы рекомендуем вам:

  1. оформить самостоятельно несколько заказов;
  2. подписаться на рассылку;
  3. посмотреть как информация об оформленных заказах и подписчиках отображается в панели администрирования магазина.

Панель управления магазином доступна по адресу: beseller-api.shop.by/manager/ . Логин и пароль при входе в панель управления аналогичны логину и паролю доступа к магазину.

Как подключиться по API к своему магазину?

Для связи приложения с вашим магазином необходимо указать url-адрес доступа к API вида:

http://адрес_вашего_сайта:8082/graphql?token=ваш_персональный_секретный_ключ

Секретный ключ вы можете получить по запросу у вашего персонального менеджера.

Функции и переменные GraphQL для работы с API платформы beseller

Как подключиться к API с использованием языка программирования PHP

Для удобства работы с API платформы beseller вы можете воспользоваться:

  1. Классами разработанными нами под PHP.
    1. GraphqlClient - осуществляет прием и передачу данных на сервер;
    2. GraphQlHelper - содержит в себе реализованные query и mutation API;
  2. Примерами использования классов для осуществления выборок и изменений в базе данных интернет-магазина.

Настройка локального окружения

Для того, чтобы наглядно продемонстрировать отправку запросов к API и получаемые ответы, вы можете воспользоваться локальным окружением.

В качестве локального окружения используется GraphiQL Feen , это расширение для браузера Google Chrome которое позволяет формировать запросы к API.

После установки приложения у вас в браузере возле адресной строки появится иконка приложения.

Откройте приложение GraphiQL Feen и перейти на вкладку «SERVERS», выберите метод отправки POST, после чего укажите url-адрес доступа к API.

В качестве тестового url необходимо использовать следующий адрес:

Локальное окружение настроено, можно формировать запросы к API. Для этого необходимо открыть вкладку «QUERIES»

Формирование запроса к API beseller при помощи GraphiQL Feen и полученный ответ

Пояснения к скриншоту:

  1. Сохраненные запросы
  2. Поле для ввода запросов
  3. Поле ввода переменных
  4. Полученный ответ
  5. Кнопка запуска

Пример запроса на получение списка оформленных заказов за указанный промежуток времени

query ($first:Int, $offset:Int, $filter: OrdersFilterType){
orders(first:$first, offset:$offset, filter:$filter){
comment
status{
id
description
name
}
create_date
update_date
total {
suffix
value
}
payment {
name
description
cost {
suffix
value
}
}
delivery {
name
description
cost {
suffix
value
}
}
currencies {
bank_code
course
suffix
}
user_data {
name
description
value
}
}
}

Указание промежутка времени для выборки данных об оформленных заказах

{
"filter": {
"date_after": "2017-11-16T00:00:01Z",
"date_before": "2017-11-23T00:00:01Z"
}
}

Пример ответа от API

{{
"data": {
"orders": [
{
"comment": "Culpa officiis vel ut.",
"create_date": "2017-11-22 16:23:28",
"currencies": [
{
"bank_code": "BYN",
"course": 10000,
"suffix": "руб."
}
],
"delivery": {
"cost": [
{
"suffix": "руб.",
"value": 0
}
],
"description": "Курьер",
"name": "custom"
},
"payment": {
"cost": [
{
"suffix": "руб.",
"value": 0
}
],
"description": "Пластиковые карты",
"name": "custom"
},
"status": {
"description": "Новый",
"id": 1,
"name": "new"
},
"total": [
{
"suffix": "руб.",
"value": 4450
}
],
"update_date": "2017-11-22 16:23:28",
"user_data": [
{
"description": "Адрес e-mail",
"name": "email",
"value": "[email protected]"
},
{
"description": "Телефон",
"name": "phone",
"value": "784.392.3949 x69329"
},
{
"description": "Адрес",
"name": "registration",
"value": "607 Erik Station Suite 057\nReynaberg, WY 83542-0037"
},
{
"description": "Комментарий",
"name": "comment",
"value": "Id nam illo optio."
},
{
"description": "ФИО",
"name": "fio",
"value": "Jordi Mann MD"
}
]
}