Перенос функционала сайта, интернет-магазина или портала в мобильное приложение имеет ряд преимуществ как для владельца онлайн-сервиса, так и для его клиентов.
Владелец получает дополнительный канал связи со своей целевой аудиторией и возможность персонализировать рекламу, а пользователь — более удобный интерфейс, дополнительный функционал и возможность получать своевременные оповещения.
Ниже вы узнаете, какие принципы и инструменты мы используем для добавления REST API в проекты.
Существует множество фреймворков, ориентированных на разработку API. Особенно много их в NodeJS, но и в других языках их предостаточно.
Однако когда стоит задача использовать существующий функционал и данные проекта, то радикально менять его архитектуру или переписывать все на другом языке или фреймворке нерационально.
Мы пишем на нашем фреймворке ZeroEngine, который ориентирован на высоконагруженные проекты и работает по принципу плагинов.
Кратко принцип работы ZeroEngine можно описать так: новый «модуль» можно встроить в любой существующий, а также перехватить управление выводом в нужный момент.
Подведем итоги входных данных
Вам нужно написать REST API для сайта.Архитектура позволяет реализовать роутер и использовать существующий функционал полностью или частично.
При разработке API в целом и API в частности мы стараемся следовать законам логики и придерживаться семантических названий, методов и параметров.
Вот примерный список внутренних требований, принятых командой ZeroTech:
ДЕЙСТВИЕ/объект/идентификатор/метод
Метод и URL-адрес должны четко описывать функцию, которую выполняет метод API. Строго говоря, при именовании метода API метод запроса (GET, POST, PUT, DELETE) — это «глагол» в предложении, а адрес — это «путь» от общего к частному.Например:
- GET /images («получить изображения») – вернет список изображений;
- POST/image – публикует изображение;
- PUT /image/123 — «помещает» переданное значение в изображение номер 123.
Семантические ошибки
Для сообщения об ошибке мы не присваиваем свои коды, а используем стандартный набор HTTP-кодов.Для упрощения обработки на стороне приложения код дублируется в теле ответа и дополняется описанием.
Мы убеждены, что предоставление разработчику приложения длинного описания всех ошибок не стоит выгоды в трафике при отладке.
Меньше методов = меньше запросов
Когда дело касается читаемости и возможности повторного использования кода, лучше использовать более независимые методы.Но при разработке API стоит максимально минимизировать количество обращений к серверу.
Проще говоря: данные, которые должны быть показаны вместе в приложении, также должны быть указаны вместе.
Не тестируйте дважды
Конечно, речь идет о дублировании функциональных тестов юнит-тестами.
Как и в других случаях, мы стараемся использовать инструменты по назначению: покрываем модульными тестами сайт и модули роутера, а сам API тестируем с помощью Dredd и API Blueprint.
Разработка через документацию
Вот почему мы используем Blueprint API и сервис пасеки.Сначала описываем, что хотим получить в итоге.
Далее продумываем структуру методов, их возвращаемые значения, варианты ошибок и т.д. Только после этого пишем API. Такой подход имеет множество преимуществ и позволяет разработчикам API быстро получать комментарии от разработчиков приложений, исключая двойную работу.
Управление версиями
Когда речь идет о мобильных приложениях, следует помнить, что не все пользователи устанавливают новую версию сразу после выпуска.Поэтому интерфейс должен быть совместим с приложениями, работающими на более старых версиях API. В этом нет ничего сложного: приложение сообщает в шапке нужную ему версию, а мы, меняя мажорную версию, перемещаем старую версию контроллера метода в подпапку с номером его (старой) версии.
Непрерывная интеграция
Мы используем TeamCity, но любой CI-сервис, включая облачный, поддерживает модульные и дредд-тесты, а также интеграцию с Apiary. Если тестирование прошло успешно, мы обновляем внешние тестовые площадки и анализируем несколько показателей.Эти действия позволяют быстро отслеживать возникшие проблемы и гарантировать, что у вас всегда будет актуальная документация.
Внедрение Unit-тестирования в существующий проект.
Возможно, вы уже захотите опробовать принципы, которые мы используем.Это значит, что в сети появится еще один хороший проект. Однако по пути вы неизбежно столкнетесь с трудностями при внедрении юнит-тестов в свой проект, если тесты для него ранее не были написаны.
Не спешите выбрасывать код и переписывать его с нуля.
Если ваш проект позволяет реализовать модуль в архитектуру, то вы можете написать модуль, позволяющий проводить выборочное тестирование.
Вы сможете писать новые модули, используя TDD, и постепенно покрывать тестами старые.
Делаем это примерно так: в папку нашего модуля устанавливаем PHPunit и его зависимости, а в теле самого модуля вызываем модифицированный testRunner:
Теги: #api #phpunit #php #Идеальный код #дизайн и рефакторинг #api$out = ''; $module = "console";
-
Космический Пейзаж
19 Oct, 24 -
Давайте Заменим Панель Задач На Док
19 Oct, 24 -
Сием, Ты Что? Мы Нормально Общались
19 Oct, 24 -
Сборка Компьютера В Сети
19 Oct, 24
