Смарт ТВ 

Что такое API? (нужно объяснение совсем для чайника)

В ероятно, вы видели термин «API». Операционная система, веб-браузер и обновления приложений часто объявляют о новых API для разработчиков. Но что такое API?

Интерфейс прикладного программирования

Термин API является аббревиатурой, и он означает «Интерфейс прикладного программирования».

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

Аналогично, API предоставляет множество операций, которые могут использовать разработчики, а также описание того, что они делают. Разработчику необязательно знать, как, например, создается операционная система и отображается диалоговое окно «Сохранить как». Им просто нужно знать, что он доступен для использования в приложении.

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

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

API упрощают жизнь для разработчиков

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

Например, если Вы хотите встроить веб-браузер для отображения одной или нескольких веб-страниц, Вам не нужно программировать собственный веб-браузер с нуля только для Вашего приложения. Вы
можете использовать WKWebView API для встраивания веб-браузера WebKit (Safari) в приложение.

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

Это относится ко всем платформам. Например, Вы хотите создать диалоговое окно в Windows? Для этого есть API . Хотите поддерживать аутентификацию отпечатков пальцев на Android? Для этого есть API , так что Вам не нужно тестировать каждый датчик отпечатков пальцев любого производителя Android. Разработчикам не нужно повторно изобретать колесо снова и снова.

API-интерфейсы управляют доступом к ресурсам

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

Например, если Вы когда-либо посещали веб-сайт и видели в своем браузере сообщение о том, что веб-сайт запрашивает Ваше точное местоположение, этот веб-сайт пытается использовать API геолокации в Вашем веб-браузере. Веб-браузеры предоставляют API-интерфейсы, чтобы веб-разработчикам было легко получить доступ к Вашему местоположению — они могут просто спросить «где вы?», и браузер сделает тяжелую работу по доступу к GPS или соседним сетям Wi-Fi, чтобы найти Ваше физическое местоположение.

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

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

Файловые системы, которые используют разрешения, как и в Windows, Mac и Linux, имеют те права, которые применяются API файловой системы. Типичное приложение не имеет прямого доступа к необработанному физическому жесткому диску. Вместо этого приложение должно получить доступ к файлам через API.

API используются для связи между службами

API также используются по другим причинам. Например, если Вы когда-либо видели объект Google Карты, встроенный на веб-сайт, этот веб-сайт использует API Карт Google для встраивания этой карты. Google предоставляет API-интерфейсы, подобные этим, для веб-разработчиков, которые затем могут использовать API-интерфейсы, чтобы собирать сложные объекты прямо на своем веб-сайте. Если таких API не существует, разработчикам, возможно, придется создавать свои собственные карты и предоставлять свои собственные данные карты, чтобы разместить небольшую интерактивную карту на веб-сайте.

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

Это относится ко многим различным онлайн-сервисам. Существуют API для запроса перевода текста из Google Translate или отображения комментариев Facebook или твитов из Twitter на веб-сайте.

Стандарт OAuth также определяет ряд API, которые позволяют Вам входить на сайт через другой сервис, например, использовать Ваши учетные записи Facebook, Google или Twitter для входа на новый веб-сайт без создания новой учетной записи пользователя только для этого сайта. API — это стандартные контракты, которые определяют, как разработчики взаимодействуют с сервисом, и вид продукции, которую разработчики должны ожидать получить.

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

Работая с 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 - создать и взаимодействовать с ним, на чем мы сфокусируемся в наших проектах.

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

Первая версия Android появилась в октябре 2008 года - всего 4 года назад, что не так много для операционной системы. За это время вышло уже более двух десятков обновлений. Основная часть обновлений включала в себя новые элементы программного интерфейса (API ), которыми приложения могли пользоваться для своих нужд. Чтобы та или иная версия Android знала, сможет ли она удовлетворить программные запросы того или иного приложения, была введена нумерация программных интерфейсов. Номер, характеризующий версию интерфейса, внедрялся в само приложение, и по нему система определяла совместимость этого приложения с собой. Этот номер назвали "уровень API" (API Level). Всего набралось уже 17 уровней, каждый последующий из которых включал в себя все функции предыдущего и добавлял новые.

Для написания приложения вместе с системой программирования на компьютер устанавливают SDK (software development kit ) — комплект средств разработки, основной частью которого является библиотека классов соответствующего API-уровня. Для каждого API-уровня существует своя библиотека, функциями которой пользуется приложение. Если мы возьмём для разработки своего приложения библиотеку первого API-уровня, то мы не получим в своё распоряжение функции, появившиеся позже. Если же мы возьмём библиотеку последнего уровня - мы рискуем сделать своё приложение несовместимым со старыми версиями Android, если вдруг используем функцию, неподдерживаемую ранее. Так как же осуществить выбор API-уровня?

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

В итоге получаем такую методику разработки приложения:

  1. Изучаем целевую аудиторию - какая версия Android установлена на их смартфонах. Если пишем для всех, то полезно будет ознакомиться с постоянно обновляемыми графиками использования той или иной версии системы на мобильных устройствах: http://developer.android.com/intl/ru/about/dashboards/index.html . На сегодняшний день видим, что основная масса уже сидит на уровне API 10, но также существуют немаленькие куски, сидящие на уровне 7 и 8. Различия в уровнях можно посмотреть тут (http://developer.android.com/intl/ru/guide/topics/manifest/uses-sdk-element.html), щёлкнув на номере соответствующего API в таблице.
  2. Если мы не хотим терять около 10% аудитории, выбираем минимальный уровень API 7. Иначе можем выбрать уровень API 10, на котором сидит сегодня почти половина пользователей. Устанавливаем соответствующий выбранному минимальному уровню SDK.
  3. Устанавливаем целевой уровень, равный минимальному, пишем и компилируем под него программу. Запускаем и тестируем её на эмуляторе смартфона с установленным API минимального уровня.
  4. После написания и отладки программы повышаем целевой уровень на единицу, компилируем программу под SDK нового целевого уровня и тестируем её в новом эмуляторе смартфона с соответствующим уровнем. Далее продолжаем повышать целевой API-уровень, компилировать и тестировать программу, пока не достигнем самого высокого API-уровня.
  5. Всё, теперь можно публиковать программу. При выходе новой версии Android с новым API-уровнем наша программа включится в нём в режиме совместимости и будет работать, как раньше. Чтобы программа заработала напрямую, а не в режиме совместимости, берём наш проект, скачиваем новое SDK последнего API-уровня, и компилируем приложение под ним. Теперь приложение запустится на новой системе в обычном режиме, и, возможно, станет выглядеть немного иначе, в традициях новой версии операционной системы. В то же время на старых версиях системы приложение остается таким, как было.
В итоге, поразмыслив, для себя я остановился на уровне API 7. Кроме того, при использовании некоторых новых функций, появившихся в гораздо более поздних API (например, фрагментов), среда разработки сама мне предложила задействовать специальный пакет совместимости, и добавила его в проект. В результате я получил возможность использовать некоторые новые функции из новых API в старом. Впрочем, это уже другая тема.

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

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

Своими словами, API предоставляет нам возможность использовать чужие наработки в своих целях. Впервые я столкнулся с API на примере Windows API. Это набор функций, которые может использовать любое приложение, запущенное на данной ОС. К примеру, оно может использовать стандартные функции для отрисовки интерфейса.

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

На сайте https://dev.hh.ru/ (а точнее, https://github.com/hhru/api/blob/master/docs/general.md) вы можете найти описание того, как клиенты и сервисы HeadHunter API взаимодействуют между собой. Например, цитата с сайта:

  • Всё API работает по протоколу HTTPS.
  • Авторизация осуществляется по протоколу OAuth2.
  • Все данные доступны только в формате JSON.
  • Базовый URL — https://api.hh.ru/
  • Даты форматируются в соответствии с ISO 8601 : YYYY-MM-DDThh:mm:ss±hhmm
Вы можете почитать HH API - это хороший пример пользовательской документации.

Форматы передачи данных

Существует множество форматов данных, с помощью которых пользователи взаимодействуют с API. Например, широко известный XML. Или JSON - легковесный и несложный формат, который выглядит как:

{ "id": "0001", "type": "donut", "name": "Cake", "image": { "url": "images/0001.jpg", "width": 200, "height": 200 } } По ссылкам ниже вы можете посмотреть ответы, приходящие от MediaWikiAPI , в разных форматах:

JSON: https://en.wikipedia.org/w/api.php?action=query&titles=Albert%20Einstein&prop=info&format=jsonfm
XML: https://en.wikipedia.org/w/api.php?action=query&titles=Albert%20Einstein&prop=info&format=xmlfm
PHP: https://en.wikipedia.org/w/api.php?action=query&titles=Albert%20Einstein&prop=info&format=php (осторожно, произойдет с качивание файла)

HTTP глаголы

Обычно при обращении к веб API используют ся запросы HTTP. Поэтому нужно хотя бы коротко сказать о стандартных методах, которые могут содержаться в HTTP запросе. Эти методы также называют HTTP глаголами:

  • GET. Наверное, самый популярный тип запроса. Используется для получения или чтения данных.
  • PUT. Обычно и спользуется для обновления ресурса.
  • POST. Обычно используется для создания нового ресурса.
  • DELETE. Удаляет данные.
  • И другие
Если мы хотим получить информацию о ресурсе, URI которого http://www.example.com/customers/12345 , мы можем послать запрос:
GET http://www.example.com/customers/12345

Если мы хотим обновить ресурс - мы можем послать PUT-запрос:
PUT http://www.example.com/customers/12345/orders/98765

Обычные GET запросы способен посылать веб-браузер. Для посылки других типов запросов могут потребоваться скриптовые языки или специальные инструменты (об этом будет ниже).

О HTTP методах можно подробнее почитать на W iki .

HTTP к оды ответов

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

Наиболее известные коды - 4xx (проблемы на стороне клиента) и 5xx (проблемы на стороне сервера). О том, какие коды возвращать в той или иной ситуации, решают разработчики самих API. Например, API сайта Одноклассники возвращает коды, описание которых можно найти на странице https://apiok.ru/wiki/pages/viewpage.action?pageId=77824003 .

Кроме того, советую послушать песню Реквест-респонс - просто и понятно о кодах, возвращаемых в HTTP запросах (осторожно, репчик:)).


REST API

REST API - э то идеология построения API, которая расшифровывается как Representational State Transfer API. Она основывается на следующих принципах , сформулированных ее создателем, Роем Филдингом :

  1. Клиент-серверная архитектура
  2. Stateless сервер
  3. Кешируемость
  4. Многослойная структура
  5. Единый интерфейс
  6. Код по требованию
Не буду углубляться в детали, желающим почитать по теме могу посоветовать