Самый востребованный IT-инструмент в компаниях и проектах

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

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

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

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

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

Базы данных обычно располагаются на удаленных серверах, а работа с ними ведется через интерфейс пользователя, предоставляемый различными приложениями. Но как данные попадают из БД прямиком на экран вашего устройства? Одним из самых частых решений этой задачи будет API.

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

Говоря о примерах применения, одними из наиболее востребованных и популярных в нашем мире являются API картографических сервисов (Google Maps, Яндекс Карты). Благодаря ним любой желающий может воспользоваться их функционалом: создать интерактивную карту и показывать, например, расположение офиса или магазина.

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

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

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

Далее Саша:

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

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

В наши дни существует множество фреймворков, облегчающих разработку API. Для начала можно обратить внимание на опросы исследования Stack Overflow Developer Survey и The State of Developer Ecosystem от Jetbrains, чтобы определить круг кандидатов для рассмотрения.

В целом, варианты можно сгруппировать по языкам программирования:

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

Итоговым вариантом для нас стал PHP-фреймворк Laravel. Признаваемый некоторыми разработчиками "умирающим" языком, PHP по-прежнему активно используется и развивается в стремительном темпе. Соответствующие веб-фреймворки свободно применяются для разработки проектов и по-прежнему занимают нишу в различных опросах и инфографиках. Laravel — самый популярный PHP-фреймворк последних лет, который привлекает внимание своей архитектурой, реализующей множество шаблонов проектирования и предоставляющей ряд удобных для разработчиков функций.

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

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

Web API состоит из нескольких конечных точек для определенной системы сообщений "запрос-ответ", обычно выраженной в формате XML или JSON с помощью веб-сервера на базе HTTP.

Здесь мы можем взять для примера стандартную клиент-серверную архитектуру:

Сервер — удаленный узел, который хранит и обрабатывает ресурсы. Здесь мы храним необходимые данные, а также устанавливаем то, как они обрабатываются и предоставляются клиентам.

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

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

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

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

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

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

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

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

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

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

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