Как подключить api к сайту php
БЛОГ ПРО WEB
Рассказываю о web-разработке
и помогаю создавать сайты
Простой API для Вашего сайта
Возникла ситуация, когда необходимо использовать 2 БД MySQL на разных серверах для снижения нагрузки.
1 БД для основных задач и 2 БД для хранения различной статистики по всем модулям. А Статистика, как всем известно, — это куча цифр, которыми не хочется засорять основную БД.
Так как решил использовать сторонний сервер, на ум приходит API. В принципе, для меня то, что нужно, так как возможно может пригодиться и для моих пользователей для вывода своей статистики на своих проектах.
Oauth использовать решил не стоит, да и было интересно как выйдет API своими руками.
API, ну или Парсер
Да, действительно, способ проще чем кажется. Можно данный способ организации назвать как Парсер, ведь будем использовать @file_get_contents()
Но мне важен результат!
Качаем исходники тут и разбираем что к чему
Собираем функционал API
У нас в итоге получится 2 части.
Файлы клиентской части
А теперь по порядку каждый файл
Клиентская часть
$url — это адрес к нашему серверу, а точнее к файлу api.php (о нем читать ниже).
Дальше мы отправляем запрос @file_get_contents($get); к серверу и получаем ответ с результатом в формате json_decode()
Начал с клиентской части потому что, мне кажется интереснее посмотреть что получится, а не то как это сделано. И поэтому, вот как использовать MySQL удаленно
Подключаем function.api.php на нужных страницах для связи с API сервера со статистикой к примеру.
А остальное все итак понятно. Там написал все 4 функции для примера, используя таблицу в бд следующего вида
И тут логично понятные параметры
query — запрос (SELECT, UPDATE, INSERT или DELETE)
table — таблица в бд (в моем случае ‘scripts’)
where — условия обычного формата (тут не стал что то изобретать. Типа, [id=5 OR >
values — и тут передаем параметры для добавления и редактирования в следующем формате
Мне кажется, просто и понятно…
Серверная часть API
Конечно же config.php
Проверка и отправка запроса в БД через класс API
Конечно как вы понимаете, проверка такого рода
лишь как пример. Тут надо делать проверку ключа и ID пользователя на соответствие. Тут проблем думаю не будет.
И файл class.a.php для разных запросов и возвращения результата
местами требуются некоторые проверки для защиты, но не критичны. Даю код, чтобы смысл был понятен. Дальше уже сами дорабатывайте)
Расписывать не буду, итак ясно что делает данный файл…
Пишем свой API для сайта с использованием Apache, PHP и MySQL
С чего все началось
Разрабатывая проект, я столкнулся с необходимостью организации клиент-серверного взаимодействия приложений на платформах iOS и Android с моим сайтом на котором хранилась вся информация — собственно БД на mysql, картинки, файлы и другой контент.
Задачи которые нужно было решать — достаточно простые:
регистрация/авторизация пользователя;
отправка/получение неких данных (например список товаров).
И тут-то мне захотелось написать свой API для взаимодействия с серверной стороной — большей своей частью для практического интереса.
Входные данные
В своем распоряжении я имел:
Сервер — Apache, PHP 5.0, MySQL 5.0
Клиент — Android, iOS устройства, любой браузер
Я решил, что для запросов к серверу и ответов от него буду использовать JSON формат данных — за его простоту и нативную поддержку в PHP и Android. Здесь меня огорчила iOS — у нее нет нативной поддержки JSON (тут пришлось использовать стороннюю разработку).
Внешний вид запросов решено было сделать таким:
http://[адрес сервера]/[путь к папке api]/?[название_api].[название_метода]=[JSON вида <«Hello»:«Hello world»>]
Путь к папке api — каталог на который нужно делать запросы, в корне которого лежит файл index.php — он и отвечает за вызов функций и обработку ошибок
Название api — для удобства я решил разделить API группы — пользователь, база данных, конент и тд. В таком случае каждый api получил свое название
Название метода — имя метода который нужно вызвать в указанном api
JSON — строковое представление JSON объекта для параметров метода
Скелет API
Скелет API на серверной стороне состоит из нескольких базовых классов:
index.php — индексный файл каталога в Apache на него приходятся все вызовы API, он осуществляет парсинг параметров и вызов API методов
MySQLiWorker — класс-одиночка для работы с базой MySQL через MySQLi
apiBaseCalss.php — родительский класс для всех API в системе — каждый API должен быть наследован от этого класса для корректной работы
apiEngine.php — основной класс системы — осуществляет разбор переданных параметров (после их предварительного парсинга в index.php) подключение нужного класса api (через require_once метод), вызов в нем нужного метода и возврат результата в JSON формате
apiConstants.php — класс с константами для api вызовов и передачи ошибок
apitest.php — тестовый api для тестирования новых методов перед их включением в продакшн версию
Теперь подробней о каждом
Я попробовал достаточно документировать файлы, чтобы не занимать много место под текст. Однако в тех файлах где нет комментариев, я все ж приведу описание.
Index.php
Как уже говорил раньше это входной индексный файл для Apache а значит все вызовы вида www.example.com/api будет принимать он.
Первым делом устанавливаем тип контента — text/html (потом можно сменить в самих методах) и кодировку — UTF-8.
Дальше проверяем, что у нас что-то запрашивают. Если нет то выводим JSON c ошибкой.
Если есть параметры запроса, то подключаем файл движка API — apiEngine.php и создаем класс движка с переданными параметрами и делаем вызов api метода.
Выходим из цикла так как мы решили что будем обрабатывать только один вызов.
apiEngine.php
Вторым по важности является класс apiEngine — он представляет собой движок для вызова api и их методов.
apiConstants.php
Данный класс используется только для хранения констант.
MySQLiWorker.php
Класс-одиночка для работы с базой. В прочем это обычный одиночка — таких примеров в сети очень много.
apiBaseClass.php
Ну вот мы подошли к одному из самых важных классов системы — базовый класс для всех API в системе.
Как видно данный класс содержит в себе несколько «утилитных» методов, таких как:
конструктор в котором осуществляется соединение с базой, если текущее API собирается работать с базой;
деструктор — следит за освобождением ресурсов — разрыв установленного соединения с базой
createDefaultJson — создает дефолтный JSON для ответа метода
fillJSON — если подразумевается что запрос вернет только одну запись, то данный метод заполнит JSON для ответа данными из первой строки ответа от БД
Создадим свой API
Вот собственно и весь костяк этого API. Теперь рассмотрим как же это все использовать на примере создания первого API под названием apitest. И напишем в нем пару простых функций:
одну без параметров
одну с параметрами и их же она нам и вернет, чтобы было видно, что она их прочитала
одну которая вернет нам бинарные данные
И так создаем класс apitest.php следующего содержания
Для удобства тестирования методов, я дописываю к ним адрес по которому я могу сделать быстрый запрос для тестирования.
И так у нас три метода
helloAPI
Это простой метод без параметров. Его адрес для GET вызова www.example.com/api/?apitest.helloAPI=<>
Результатом выполнения будет вот такая страница (в браузере)
helloAPIWithParams
Этот метод принимает в параметры. Обязательным является TestParamOne, для него и сделаем проверку. Его его не передать, то будет выдан JSON с ошибкой
helloAPIResponseBinary
И последний метод helloAPIResponseBinary — вернет бинарные данные — картинку хабра о несуществующей странице (в качестве примера)
Как видно — здесь есть подмена заголовка для вывода графического контента.
Результат будет такой
Есть над чем работать
Для дальнейшего развития необходимо сделать авторизация пользователей, чтобы ввести разграничение прав на вызов запросов — какие-то оставить свободными, а какие-то только при авторизации пользователя.
Ссылки
Для тестирования выложил все файлы на github — simpleAPI
Создание современного API на PHP в 2020 году
Итак, на примере этого API, я хочу показать современную PHP архитектуру для высоконагруженных проектов. Когда проект еще в самом начале, и не то, что бизнеслогика (взаимоотношения с базой данных) не прописана, но и сама бизнес модель не очень ясна, построение эффективной IT архитектуры может идти только одним путем: необходимо жестко разделить frontend и backend.
Что обычно делали в таких ситуациях два-три года назад? Брался монолитный фрейворк типа Laravel или Yii2, вся бизнес модель разбивалась, худо-бедно, на блоки, а эти блоки уже имплементировались как модули фреймворка. В итоге еще через 3 года получалась огромная не поворотная машина, которая сама по себе медленная, а становилась почти невыносимо медленной, в которой фронтенд рендится через бэкенд посредством классической MVC архитеркутуры (пользователь отправил запрос, контроллер его подхватил, вызвал модель, та в свою очередь чего-то там натворила с базой данных, вернула все контроллеру, а тот наконец-то вызвал вьювер, вставил туда данные из модели и отдал это все пользователю, который уже успел открыть очередную банку пива. ). А… ну еще особо продвинутые ребята, они не просто вьюверели Tweeter Bootstrap, а во вьювер вкручивали на самом деле очень хорошие библиотеки типа JQuery или вместо вьювера использовали какой-нибудь фронтенд фреймворк. В итоге поддерживать такой БеЛаЗ становилось все сложнее, а ввести нового программиста в команду было очень сложно, ибо не все рождаются Энштейнами. Добавим сюда тотальное отсутствие документации разработчика (камменты в 9000 файлах почитаешь — там все есть!) и в итоге, смотря на это все, становилось по-настоящему грустно…
Но тут произошел ряд событий, который в корне изменил ситуацию. Во-первых, наконец-то, вышли стандарты PSR и Symfony внезапно перестал быть единственным модульным фремворком, во-вторых, вышел ReactJS, который позволил полноценно разделить фронтенд от бэкенда и заставить их общаться через API. И добивая последний гвоздь в крышку гроба старой системы разработки (MVC — это наше все!) выходит OpenAPI 3.0, собственно, который и регулирует стандарты этого общения через API между фронтендом и бэкендом.
И в мире PHP стало возможно делать следующее:
Теперь становятся вопросы, точнее два вопроса, а что у нас перед API и соответственно, что у нас «под хвостом» после API.
1.«Там вдали за рекой», далеко перед API у нас цветет, расползается на новую функциональность и картинки — ФРОНТЕНД (Предпочтительнее ReactJS, но Vue тоже сойдет. Хотя там из коробки всего столько много, что утяжелять процесс он будет, а вот насколько в реальной жизни это понадобится — не совсем понятно и зависит напрямую от бизнес модели). И НЕТ! Я к этому зверю даже близко подходить не буду, ибо с детства у меня на него аллергия. Тут нужен отдельный специалист. Я не фулстак и не пишу фронтенд.
2. Прямо вот перед самим API у нас… НЕ УГАДАЛИ… не NGINX, а RoadRunner roadrunner.dev/features. Заходим, читаем, понимаем, что это быстрее и вокеры расписываются по количеству процессоров, а посему никогда не будет таблички «МЫ НА ПРОФИЛАКТИКЕ», ибо просто надо вокеры переключить.
И на этом моменте хочу остановиться подробнее. Ибо в моем понимании есть три пути «как мух ловить», запросы то бишь…
1. В случае если весь API написан уже, и будет написан в дальнейшем, на PHP — голову ломать не зачем, ставим RoadRunner с prometheus.io
2. В случае, если система собирается из разных кусков, разные сервисы написаны на разных языках и дальше тоже не понятно на чем их писать будут:
2.1. Ставим NGINX UNIT — пользуемся поддерживаемыми языками.
2.2. Поднимаем ВСЕ РАВНО КАКУЮ систему контейнеров, Docker, LXC, LXD. Выбор опять же зависит от размера проекта — поддерживать сборку PROXMOX-LXC на хостинге в 12 процессоров, c 32Гб памяти, за 40 евро в месяц будет в разы дешевле, чем Docker сборки на Google Cloud Platform. В каждый контейнер ставим подходящий к языку сервер, и связываем все это HAProxy www.haproxy.org. HAProxy — шикарный балансер и прокси сервер который в корпоративной среде, не менее популярен, чем NGINX. Что он делает, а чего нет, читаем тут cbonte.github.io/haproxy-dconv/2.3/intro.html пункт 3.1. При такой архитектуре сервисы или микросервисы могут писаться на чем угодно и никто не зависит от ограничений накладываемыми RoadRunner или NGINX UNIT.
3. «Под хвостом» — Cycle ORM. Не ленимся, смотрим видео, что будет стоять за ней конкретно MySQL или PostgreSQL- опять, я бы оставил на после того, как будет понятна бизнес схема проекта. MySQL проще масштабируется, в PostgreSQL — больше бизнес логики перенесенной внутрь самой базы.
4. Пример, который можно посмотреть и пощупать. Там за основу взято тестовое задание. Все самые полезные вещи находятся в папке EXTRAS. Там уже есть jar file генератора, YAML swagger файл API, сгенерированный API stub через OpenAPITools в SLIM4. Даже с аутентификацией и middleware. Документация на API сгенрированная, правда swagger, не OpenAPITools. Предполагается, что некоторые юзеры залогинены и им выдан токен. Там уже стоит RoadRunner впереди. Стек — PHP 7.4.10, PostgreSQL 12.4.
В данной статье вы узнаете, как создать простой REST API в PHP.
1. Обзор проекта
1.1 Что такое REST API?
REST API позволяет вашему приложению взаимодействовать с одним или несколькими различными приложениями, используя концепции REST.
1.2 Зачем нужен REST API?
Во многих приложениях REST API необходим, потому что это самый легкий способ создания, чтения, обновления или удаления информации между различными приложениями через Интернет или протокол HTTP. Эта информация представляется пользователю в одно мгновение, особенно если вы используете JavaScript для отображения данных на веб-странице.
1.3 Где используется REST API?
REST API может использоваться любым приложением, которое может подключаться к Интернету. Если данные из приложения могут быть созданы, прочитаны, обновлены или удалены с помощью другого приложения, это обычно означает, что используется REST API.
2. Файловая структура
3. Настройка базы данных
3.1 Создание таблицы категорий
3.2 Дамп данных для таблицы категорий
3.3 Создание таблицы товаров
3.4 Дамп данных для таблицы товаров
3.5 Подключение к базе данных
Приведенный ниже код показывает учетные данные базы данных и метод для получения подключения к базе данных с помощью PDO.
Создайте папку api и откройте её. Создайте папку config и в ней создайте файл database.php со следующим кодом.
4. Получение товаров
4.1 Создание объекта Product
Код ниже содержит класс с именем Product и несколько свойств. Также показан метод конструктора, который принимает соединение с базой данных.
4.2 Создание файла для чтения товаров
Код ниже содержит заголовки о том, кто может читать этот файл и какой тип содержимого он будет возвращать.
4.3 Подключение к базе данных и таблице товаров
Замените комментарий // подключение к базе данных будет здесь в файле read.php следующим кодом.
4.4 Чтение товаров из базы данных
Замените комментарий // чтение товаров будет здесь в файле read.php следующим кодом.
4.5 Создание метода read()
4.6 Уведомление пользователя о том, что товары не найдены
Замените комментарий // ‘товары не найдены’ будет здесь в файле read.php следующим кодом.
5. Создание товаров
5.1 Создание файла create.php
Откройте папку product и создайте в ней файл create.php со следующим содержимым.
5.2 Создание метода create()
6. Получение одного товара
6.1 Создание файла read_one.php
6.2 Создание метода readOne()
7. Обновление товара
7.1 Создание файла update.php
7.2 Создание метода update()
8. Удаление товара
8.1 Создание файла delete.php
Откройте папку product и создайте файл delete.php со следующим содержимым.
8.2 Создание метода delete()
9. Поиск товаров
9.1 Создание файла search.php
В папке product создайте файл search.php со следующим кодом.
9.2 Создание метода search()
10. Пагинация товаров
10.1 Создание файла read_paging.php
В папке product создайте файл read_paging.php со следующим кодом.
10.2 Создание файла core.php
Этот файл содержит нашу базовую конфигурацию, такую как базовый URL и переменные пагинации.
Откройте папку config и создайте в ней файл core.php со следующим содержимым.
10.3 Создание метода readPaging()
10.4 Создание метода count()
Так же в классе Product (файл product.php) добавьте метод count() для создания массива пагинации.
10.5 Получение массива пагинации
11. Получение категорий
11.1 Создание объекта Category
Откройте папку objects и создайте новый файл category.php со следующим кодом.
11.2 Создание файла read.php
Создайте новую папку category в корне, и в ней файл read.php со следующим кодом.
11.3 Создание метода read()
Если вам понравилась данная статья, рекомендую к прочтению создание регистрации и авторизации в php с использованием JWT.
Надеюсь, вам понравилась данная информация. Если вам интересна тема web-разработки, то можете следить за выходом новых статей в Telegram.
Рекомендации при подключении API
Как мы интегрировали в наш проект много разношерстных API, с какими проблемами столкнулись и какие решения нашли.
Владислав Балаклейский, Технический директор Aviata.kz
Сегодня расскажу о том, как мы интегрировали в наш проект много разношерстных API, какие проблемы мы выловили и какие выводы из этого сделали.
Как вы понимаете, весь наш сервис построен на работе с API.
В рамках этой презентации я условно разбиваю API на 2 типа: доступные и закрытые.
Под доступными подразумеваются в первую очередь открытые, широко распространенные, хорошо документированные API, с большим комьюнити. За примерами далеко ходить не придется и вы о них наверняка слышали. Мы используем AWS SES, Google Drive, Firebase. К тому же очень часто для их использования уже есть набор готовых клиентов под разные языки программирования. Также есть комьюнити и возможность вести обсуждение или искать решение багов в stack overflow.
Зачастую доступ к таким API и к документации открывается только после подписания договора. Получается что у нас нет открытого комьюнити, где мы можем обсудить проблемы или коллективно решить баги.
Когда я составил для себя этот список проблем, я понял что такие же симптомы есть и в наших собственных API. Давайте пройдемся по деталям и найдем к ним верное решение.
Что же нужно запросить от поставщика, чтобы как можно скорее начать работу.
Ранее мы с вами говорили о том, чтобы писать клиент на основе самого сложного и разнообразного кейса в вашем процессе. Но когда вы получили доступы в тестовую среду, получили документацию и примеры запросов я советую провести тест всего процесса с минимальным количеством данных. Взять Postman или аналогичный инструмент для отправки запросов и отправить сырые запросы например (XML) от авторизации до выписки билетов. Если MVP требует реализации возвратов билетов, проверьте и их тоже. Почему это важно? На стороне поставщика не всегда все сразу настроено как положено. Для нас с вами это черный ящик, мы даже не подразумеваем какие у них есть настройки, локали, и т.д. Лучше сразу понять что не работает из всего процесса, чтобы поставщик это исправил, настроил, пока вы только начинаете интеграцию.
Когда приходит задача интегрироваться с сложным API, очень часто хочется как можно скорее просто начать работать. Это может быть ошибкой.Например, делая одну из интеграций мы по готовой инструкции сделали запрос на поиск из Алматы в Нур-Султан на 1 пассажира. Получили результаты с перелетами, и даже забронировали билет. Все это сделали сразу в клиенте.
У этого параметра такое количество значений:
Стоит ли говорить о том, что описания к этим значениям в API нет. Не зная, на что он в принципе влияет, мы использовали то, что было дано в примере и вроде бы все пошло хорошо. Нам вернулись результаты поиска:
По сути это одноуровневый список перелетов, но так как мы запрашивали перелет туда-обратно, а нам выдали список перелетов из одного уровня, то мы начали комбинировать их друг с другом, складывая стоимость перелета, учитывать время вылета, если это полет туда и обратно в один и тот же день, сортировать по цене. CombinabilityNestedRoundtripOnlyLowestFarePerFareType сразу. Вот только этот параметр меняет структуру выдачи и теперь она выглядит так:
Оказывается все это уже готово на стороне API и мы можем для этого использовать параметр CombinabilityNestedRoundtripOnlyLowestFarePerFareType сразу. Вот только этот параметр меняет структуру выдачи и теперь она выглядит так:
В первом случае оказывается мы начали нагружать авторизационный сервис. В документации не было описано, что авторизационный токен надо хранить до его истечения в кэше поставщика и использовать его на любые следующие запросы. В итоге мы на каждый наш запрос выписывали новый токен.
В итоге мы переписываем часть клиента, отвечающего за поиск, чтобы он учитывал вложенные перелеты и не комбинировал самостоятельно.
Похожая ситуация произошла и для бронирования пассажиров. С бронированием взрослых и детей не было проблем. Но для бронирования младенца в дополнительных параметрах надо проставлять своего взрослого. Это привело к переписыванию клиента в части бронирования.
Например, для интеграции сервиса ЖД мы использовали свои данные для бронирования, однако уже в релизе столкнулись с тем, что Казахские символы не отображались в PDF билете, который генерировался из HTML. Пришлось экстренно костылить библиотеку, которая сначала генерировала docx файл с казахским шрифтом, а уже оттуда делали PDF.
Какой следует из этого вывод? Для интеграции надо сразу использовать наиболее сложный процесс и с самыми разными и что важно реальными данными. Для написания клиента это будет сложно и займет много времени, но зато сэкономит нервы при переписывании его.
Старые API очень часто используют XML\WSDL форматы. Как по мне это устаревшие и сложные для чтения\восприятия форматы. И к тому же, они многословные, что по итогу приводит к большому объему данных. Например, некоторые GDS на результаты поиска выдают 1.6 мб данных, а если запросить результаты на соседние даты, то получится 20 мб. Это накладывает свой отпечаток на скорость обработки. Поэтому когда мы использовали библиотеку suds для обработки SOAP\WSDL результатов, у нас все тормозило. Пришлось переключиться на стандартную низкоуровневую библиотеку xml. Работать с ней не так приятно, но скорость важнее. Поэтому проверьте какой объем данных вы получаете от API и сравните производительность разных библиотек.
Тоже самое касается и хранения данных. В результате бронирования нам приходит огромный пласт данных в XML. Не все эти данные нам нужны для использования в проекте, поэтому мы выделяем нужные и сохраняем в удобном нам формате. Раньше мы распределяли их по сущностям в классы с большой вложенностью, практически как в исходном XML ответе. А затем сохраняли сериализованный класс в базу. Это отстой, не делайте так. Потому что с годами ваши классы обрастают новыми методами и атрибутами, и когда спустя время вы десериализуете старую бронь у нее не будет этих методов. Лучше переводите все в JSON структуру. Весит меньше, легче читается.
В 2 из 5 случаях подключения к API у нас возникали трудности с авторизацией. Обычно до запуска в продакшн на моменте тестирования вы отправляете запросы и API сервис реагирует вполне нормально. Отдает ответ вовремя, без задержек и ошибок. Что происходит, когда вы выкатываете ваш сервис в продакшн? Параллельно пойдут сотни и тысячи запросов в API.
В первом случае оказывается мы начали нагружать авторизационный сервис. В документации не было описано, что авторизационный токен надо хранить до его истечения в кэше поставщика и использовать его на любые следующие запросы. В итоге мы на каждый наш запрос выписывали новый токен.
Во втором случае авторизационная сессия становилась невалидной после процесса бронирования. Поэтому для каждого нового процесса (от поиска до бронирования) надо было запрашивать новую сессию.
Так что внимательно и детально уточняйте процесс работы с авторизацией.
В заключении у нас получается что-то вроде чек-листа, который поможет избежать множества сложностей в подключении API. Это также сэкономит время и нервы разработчиков.
К сожалению, чек-лист не является решением всех проблем, и будет здорово, если мы сможем все вместе его дополнить в комментариях.