Download the PHP package ioncurly/vetmanager-api-gateway without Composer

Простыми словами, объект ApiGateway - связующее звено с работой с АПИ Ветменеджера. Больше ничего создавать не нужно будет

1. С помощью субдомена и АПИ ключа

2. С помощью полного пути к серверу и АПИ ключа

3. С помощью субдомена, имени АПИ-сервиса и АПИ ключа (для специальных внутренних сервисов)

4. С помощью полного пути к серверу, имени АПИ-сервиса и АПИ ключа (для специальных внутренних сервисов)

Вся логика получения Active Record вынесена в соответсвующий Facade. Вот пример получения клиента по ID:

То есть в этой библиотеке для каждого вида Active Record существует свой Facade. В Facade выделена логика работы АПИ-запросов и получения из ответов Active Record. Например, в Facade для Active Record Client содержится метод получения соответствующего Active Record по ID. Так же в Facade содержатся и другие методы получения (в том числе - через более сложные запросы - например, через фильтры).

Существуют Active Records, которые могут быть получены лишь с помощью конкретного АПИ-запроса. Например, MedicalCardByClient можно получить лишь по ID клиента. Недоступные методы получения в соответствующем фасаде просто не существуют

Всегда возвращает массив моделей. Даже когда 1 объект получаем - обращаемся к нему через массив.

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

Ниже перечислены 3 варианта одного и того же запроса

1) С помощью Query Builder

[Ссылка на используемую библиотеку с большим количество примеров использования Builder](https://github.com/otis22/vetmanager-rest-api)

2) С помощью PagedQuery

[Ссылка на используемую библиотеку с большим количество примеров использования PagedQuery](https://github.com/otis22/vetmanager-rest-api)

С помощью этого объекта удобнее работать с пагинацией.

3) С помощью Get Parameters в виде строки

Сюда можно передать все те же Get-параметры, используемые в коллекции Postman. Более подробно о фильтрах, сортировке
и т.д. здесь - [Vetmanager REST API Docs](https://help.vetmanager.cloud/article/3029)

Получать каждое свойство через гет-метод. Типизация в каждом методе есть

Есть свойства объекта, которые вместо скалярных данных, возвращают другие объекты или массив объектов.

Пример обращения посложнее:

Та же запись, но с дополнительными переменными для понимания:

С помощью этих методов несложно реализовать кеширование модели.

Каждый раз, когда нужно сделать повторяющийся одинаковый запрос:

1 - Попытаться получить уже закешированный объект в виде массива.

• Если нашелся кеш:

  2 - создать объект из этого кеша.

• Если не нашелся кеш:

  2 - сделать АПИ запрос на получение объекта

  3 - в кеш закинуть модель в виде массива для следующей PHP сессии

Получение модели в виде массива

Возвращаются данные в том же виде, в котором и были получены по АПИ

Создание объекта из данных в виде массива

1. Получение одного объекта из закешированного массива модели (в виде ['id' => '12', '...' => ...]).

2. Получение массива объектов из массива таких массивов с моделямм

Например, у моделей User и Client есть геттер для FullName. У объекта FullName есть методы возвращающие полное имя в разном формате:

Если, предположим, отчества не будет, то каждый из методов просто пропустит слово без создания лишних пробелов, точек и т.д.

Например, у модели Клиники есть метод возвращающий FullPhone. У FullPhone есть метод возвращающий телефон с кодом страны и выбранной маской номера, например в виде: +7(918)-277-21-21

Несколько вариантов. Возвращается bool:

Используемые библиотеки

• Symfony Serializer - Для создания DTO из массива данных (десериализованный JSON) и обратного процесса ( нормализации)
• Guzzle HTTP client - Для всех используемых запросов

• vetmanager-rest-api - Помощник с Query-запросами АПИ Ветменджера

  Только при разработке:

• PSALM
• PHPUnit

Внутренние особенности

Для большинства моделей АПИ Ветменджер кроме запрашиваемой модели отдает и содержимое других связанных моделей. Это также зависит от вида запроса - например, при запросе по ID обычно приходит наибольшее число связанных моделей. Для пользователя этой библиотеки это скрыто: в любом случае вне зависимости от какой вида Active Record получен - все методы и связи с другими моделями доступны. А как именно при вызове метода будут получаться данные: из уже полученных данных или при помощи дополнительного запроса - это тоже берет на себя библиотека.

Вот пример для понимания устройства. Но для использования это вовсе неважно. В использовании каждый из полученных Active Record идентичен (так как обладают одним и тем же набором доступных методов, которые просто реализованы по-разному):

Разработка

1. Копируем файл окружения из примера

2. Заполняем .env

3. Устанавливаем библиотеки

4. Запуск юнит-тестов

Можно запускать другие команды, примеры можно посмотреть в composer.json в разделе scripts. Например: