Наверняка многие из вас слышали о таком термине, как API. Но только единицы напрямую взаимодействовали с ним либо были причастны к созданию данного программного комплекса. Если абстрагироваться от веб-разработки, то под API обычно подразумевают некий интерфейс, при помощи которого пользователь или другое приложение имеет возможность взаимодействовать с программой.
Программное API работает примерно также. Внешний пользователь или приложение получает доступ только к ограниченному количеству действий, которые и определяются интерфейсом API.
Самые крупные сайты и сервисы, такие как VK, Twitter, Facebook - имеют в своем распоряжении достаточно сложные и разветвленные АПИ, иногда даже несколько. Основная цель разработки таких АПИ - создать возможность взаимодействия с ними сторонних приложений. В частности, у всех крупных соцсетей есть собственные приложения под разные мобильные устройства, под десктопы. И АПИ является одновременно поставщиком данных для этих приложений и окном доступа к тем или иным методам - логин, написание сообщения, чтение новостной ленты и т.д.
Приведем более детальные примеры. Допустим, сайт позволяет зарегистрировавшемуся пользователю добавлять других пользователей в друзья, писать личные сообщения, создавать посты, оценивать их и делать многое другое. Каждое из этих действий программируется на нескольких уровнях - уровне базы данных (структура данных и сами данные), уровне бэкенд-логики (методы и функции в программном коде, отвечающие за обработку, выборку данных, их преобразование) и уровне представления (отрисованная html-страница с такими элементами управления, как кнопки, ссылки, поля формы). Соответственно, самый верхний уровень (страница html) является неким интерфейсом взаимодействия с сайтом для конечного пользователя.
При расширении и развитии сайта, при увеличении его посещаемости может возникнуть необходимость создать под него мобильные приложения, обладающие примерно тем же функционалом, что и сам сайт. Другими словами, пользователи данных приложений также должны иметь возможность оставлять комментарии, писать личные сообщения, создавать посты и делать прочие нужные им действия. И тут возникает логичный вопрос - как связать уровень представления (в данном случае это окошко мобильного приложения) с уровнем бэкенд-логики и базой данных, которые хранятся где-то на стороннем сервере? Ответ - создать прослойку в виде АПИ.
Как правило, данный программный комплекс представлен в виде набора эндпоинтов (роутов, маршрутов, url адресов), каждый из которых отвечает за какое-то отдельное действие пользователя / самого приложения. Ниже приведем примеры эндпоинтов какого-то вымышленного АПИ и опишем приблизительную схему их составления.
GET /feed
GET /feed/{user_id}
GET /messages
GET /messages/{message_id}
POST /messages
PUT /messages/{message_id}
GET /users/{user_id}
POST /users
POST /users/{user_id}/ban
Для каждого роута сначала указан http-метод, при помощи которого он выполняется, а затем - паттерн url-адреса. Метод GET может быть выполнен посредством простого открытия указанного url в строке браузера. POST и другие методы, как правило, выполняются при помощи специальных программных инструментов (тот же cURL) или дополнительно устанавливаемого ПО, к примеру, приложения Postman.
Два первых роута, судя по названию, могут отвечать за функционал новостной ленты. Первый роут позволяет получать ленту текущего пользователя сайта (того, за которого вы залогинились), либо, к примеру, новости всех пользователей сразу. Во втором роуте есть динамический параметр - user_id, позволяющий уточнить, ленту какого именно пользователя мы хотим получить. Роуты с третьего по шестой работают с функционалом сообщений на сайте. Как не сложно догадаться, третий роут отдает нам список всех сообщений текущего пользователя, четвертый роут - отдает информацию о каком-то конкретном сообщении по его id. Пятый - за счет смены http-метода с GET на POST позволяет создать новое сообщение (все параметры которого, к примеру, текст, id автора, id получателя передаются уже в теле запроса, а не в url). Шестой метод нужен для редактирования какого-то конкретного сообщения. О том, что сообщение именно редактируется, косвенного говорит метод PUT. Методы с 7 по 9 отвечают за работу с пользователем. Седьмой - отдает информацию о конкретном пользователе по id, восьмой - позволяет создать (зарегистрировать) нового пользователя на сайте. Девятый - позволяет забанить пользователя по id (к примеру, если вы являетесь админом).
Как мы видим выше, роуты можно разделить на отдельные группы по признаку схожего функционала или из-за того, что они работают с одной либо близкими по смыслу сущностями. В данном случае явно выделяются три группы - feed, messages, user. Естественно, надо понимать, что в реальных АПИ самих групп и методов в них может быть гораздо больше.
Чем же обусловлен конкретный состав роутов в АПИ сайта? Прежде всего,ограничением функциональности приложений, которые будут использовать данное АПИ. К примеру, в приложении нет экрана, где бы демонстрировался список пользователей, поэтому нет нужды в роуте GET /users (в списке выше он отсутствует). Но вряд ли будут какие-то технические сложности в плане реализации этого метода, если он вдруг понадобится.
Также следует понимать, что почти всегда на каких-то методах АПИ есть ограничения по доступам к ним. К примеру, часть методов может быть доступна абсолютно любому пользователю, даже если он не залогинен / не зарегистрирован. Характерный пример - какой-нибудь метод GET /search, позволяющий искать информацию по сайту. Другие методы могут быть доступны всем залогиненным пользователям. Третьи - только тем, кто, к примеру, купил платную подписку или какой-либо товар на сайте (метод оставления отзыва на товар). Четвертые - доступны только модераторам сайта (метод бана / разбана пользователя, редактирования чужих постов и сообщений). Пятые - только главному админу.
В каком же формате АПИ обычно предоставляет информацию? На данный момент распространены два основных формата - xml и json. В стандартной веб-разработке чаще всего используется последний формат. Главные причины популярности json - меньший вес данных, более простая и понятная структура. Кроме того, ответ в формате json, как правило, не привязан к какой-то жесткой схеме в плане расположения данных друг относительно друга и типу переменных.
