Структурирование функциональности API
У меня нет большого опыта в создании API. Я проделал значительную часть работы по интеграции WordPress со сторонними API, но я потратил очень мало времени на создание системы, имеющей свой API, с которым могут взаимодействовать другие системы.
Что касается последнего, я на самом деле занимаюсь этим (и многому учусь). Суть проекта в том, что есть приложение для iOS, которое взаимодействует с WordPress через REST API двунаправленным образом.
Я очень хочу рассказать об этом больше, но мне нужно сделать это, когда проект будет продвигаться дальше.
Но когда дело доходит до работы со сторонними API, а затем создания взаимодействующих с ними компонентов проекта WordPress, я постоянно нахожу полезными две вещи:
- используя правильную библиотеку ,
- схема системы,
- разделение функциональности на части.
И последние два пункта выше — это то, что я хочу осветить в этом посте.
Структурирование функциональности API
В этом посте нет никакого кода, но, возможно, он будет руководством к тому, как вы можете продвигаться вперед в своей работе, выполняя структурирование функций API или делая что-то подобное самостоятельно.
Сторонние библиотеки
Я упоминаю об этом только потому, что считаю полезным повторно использовать проверенные и надежные решения, которые были проверены (и, следовательно, использованы) повсеместно в различных проектах.
Guzzle — моя любимая библиотека. Да, в WordPress есть встроенные функции для связи с другими URL-адресами, но с Guzzle вы можете сделать больше (особенно в том, что касается компонентов запроса), чем с WordPress.
Конечно, это мое мнение, но мне нравится с ним работать. И документация солидная.
Схема системы
Когда вы достаточно долго работаете с интеграцией со сторонними API, вы должны привыкнуть к процессу настройки работы системы. Обычно это происходит примерно так:
- создать клиент API для подключения к API,
- настройте функции, необходимые для выполнения необходимых вам запросов,
- разобрать ответ,
- вернуть его исходному объекту или функции, вызвавшей запрос.
Это немного упрощение (в конце концов, создание клиента API может быть задачей само по себе), но все пункты остаются прежними (и не могут стать плохой серией 🤔).
В любом случае, прежде всего, никогда не помешает составить схему системы. Это то, чем я все еще занимаюсь, потому что это помогает мне, в некотором смысле, сформулировать, что именно я создаю, и посмотреть, есть ли пробелы в потоке управления через приложение.
Вот почему, если не по какой-либо другой причине, это важно: формулирование того, что вы собираетесь делать, помогает вам понять, что вы делаете, и часто обнажает пробелы в вашем мышлении, которые вы считаете само собой разумеющимся.
Поэтому, когда дело доходит до разработки системы, не думайте, что вы уже все продумали.
Разделение функциональности
Если вы читали этот блог какое-то время, то знаете, что я являюсь поклонником идеи разработки «разделения интересов».
Это верно по нескольким причинам, наименьшая из которых не является:
- возможность изолированного модульного тестирования клиента API,
- сохраняя независимость кода для связи с интерфейсом и сервером.
Когда у вас есть класс, предназначенный для выполнения бизнес-логики со значениями, вы можете переложить большую часть обработки ошибок на промежуточный класс.
Это означает, что базовый класс, отвечающий за большую часть бизнес-логики, должен иметь именно то, что ему нужно для выполнения своей работы. Это не означает, что не должно быть какой-либо проверки ошибок (деление на ноль или что-то в этом роде, понимаете?), но это означает, что данные могут быть проверены еще до того, как они попадут в основной класс через промежуточный класс.
И он может не только проверять недостающую информацию, но также может сообщать об этих ошибках обратно во внешний интерфейс.
Три момента, которые нужно помнить
Если вы создаете Ajax-зависимую систему в WordPress, смысл всего этого трижды:
- схему системы, которую вы создаете,
- создать промежуточный класс для обработки любой отсутствующей информации и сообщить об ошибках,
- отправляйте полную информацию основному бизнес-классу только после того, как вся информация будет проверена.
После того, как вы это сделаете, цель будет заключаться в том, чтобы основной бизнес-класс возвращал запрошенные значения без ошибок, поскольку они будут перехвачены еще до того, как они достигнут этого.