Структурування функціональних можливостей 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, сенс усього цього полягає в трьох аспектах:
- схема системи, яку ви створюєте,
- створити проміжний клас для обробки будь-якої відсутньої інформації та звітувати про помилки,
- надсилайте повну інформацію до основного бізнес-класу лише після перевірки всієї інформації.
Після того, як ви це зробите, мета полягатиме в тому, щоб основний бізнес-клас повертав запитувані значення без помилок, оскільки вони будуть перехоплені, навіть не досягнувши їх.