Пишемо api gem вибір структури та інструментів, статті про програмування mkdev
DevOps консультант, експерт з AWS, OpenStack, Puppet, Ansible, програміст на Ruby і Go, технічний директор і засновник mkdev.me.
В першу чергу я додам можливість аутенфіціровать запити до GrooveHQ API. а потім напишу мінімальний необхідний код для отримання списку всіх тікетів. На щастя, документація у API цього сервісу вичерпна і зрозуміла, тому зробити один GET-запит труднощів не складе.
мінімальний клієнт
Якщо ти з працею уявляєш собі що таке API і навіщо він потрібен, то перервемо на п'ять хвилин і прочитай нашу статтю на цю тему.
Я почну з того, що напишу невеликий клас GrooveHQ :: Client. який буде відповідальний за проведення запитів до API. Конструктор цього класу буде приймати access token.
Як звертатися до API
Тепер потрібно розібратися, як звертатися до API. До цього моменту я ніколи не використовував гем httparty для проведення запитів. Мій досвід обмежується бібліотеками RestClient і Faraday. Не думаю, що є велика різниця, яку бібліотеку використовувати, але щоб зробити процес більш цікавим виберу httparty. Тим більше що у нього зірочок на GitHub багато :)
Насправді, терпіти не можу Faraday.
Додаю наступну сходинку в groovehq.gemspec:
і виконую bundle install. Залишилося тільки підключити httparty всередині ./lib/groovehq.rb:
Робимо перший запит до API
Перевіримо, чи все працює як треба, виконавши в папці з гемом команду bundle exec irb. Потім один за іншим виконаємо наступні шматки коду:
В результаті, якщо використаний коректний access token, ти отримаєш в консолі хеш приблизно такого вигляду:
Здається, у нас є мінімально працююча версія гема! Комміт зі змінами тут: f7d9eef.
Метод #perform_request створений не більше ніж для дебаггінга, тому він не містить будь-якого більш правильного створення рядків-посилань.
додаємо структуру
Вивчивши документацію до httparty. я побачив, що цей гем дозволяє писати прості і красиві класи, відповідальні за проведення запитів. Можна вказати глобальні настройки для кожного запиту (base uri, заголовки і т.п.), а кожен метод класу буде відповідальний за якийсь конкретний запит.
Переписаний GrooveHQ :: Client таким чином виглядає так (метод #perform_request вже не потрібен):
Тепер потрібно додати окремі методи для кожної API точки. Щоб не городити десятки методів прямо в класі GrooveHQ :: Client. я розіб'ю їх на окремі модулі, де кожен модуль відповідає певному ресурсу.
Точно так же це реалізовано в геме octokit. де я і підгледів цей підхід.
Додаю папку lib / groovehq / client з файлом tickets.rb:
Експеримент в irb показав, що все працює як треба і перший API endpoint обгорнутий гемом і готовий до використання.
Що далі?
Наступною моїм завданням буде додати якомога більше ресурсів, слідуючи документації API. Про проблеми, з якими я зіткнуся в процесі - в наступній статті.
Ще по темі
- Пишемо API gem: що таке Hypermedia API і як з ним подружитися
- PostgreSQL: навіщо і як
- Незамінний навик: дивитися в логи
Нарешті вирішив зайнятися самоосвітою?
Тоді почни з нашого безкоштовного путівника по світу веб-розробки. Усередині купа корисних порад і матеріалів для самостійного вивчення.
дістати книгу
