Лучшая практика архитектуры Wrapper API

Question

Я пишу модуль-обертку Perl вокруг веб-службы REST и надеюсь получить несколько советов о том, как лучше всего спроектировать модуль.

Я искал пару различных модулей Perl для вдохновения.

Flickr::Simple2 - это, по сути, один большой файл с методами, охватывающими различные методы в Flickr API, например, getPhotos() и т. Д.

Flickr::API - это подкласс другого модуля ( LWP ) для выполнения HTTP-запросов. Таким образом, в основном это позволяет вам делать вызовы через модуль, используя LWP, которые переходят на правильный метод API / URL-адрес без определения каких-либо методов-оболочек. Это объясняется довольно плохо - но в основном у него есть метод, который принимает аргумент (имя метода API) и создает правильный вызов API, например, request() / response().

Альтернативный дизайн будет похож на первый, но менее монолитный, с отдельными классами для отдельных «областей» API.

Я бы хотел следовать современным / лучшим методам Perl, поэтому я использую Dist::Zilla для сборки модуля и Moose для OO, но я ' Буду признателен за информацию о том, как на самом деле спроектировать / спроектировать мою обертку.

Будем признательны за руководства / учебные пособия или ссылки на другие хорошо спроектированные модули.

Приветствия

Answer 1

У Джошуа Блоха есть хорошие советы на тему " Как разработать хороший API и почему он имеет значение " (видео, 2007).

слайды (PDF) .

Answer 2

Это в некоторой степени зависит от широты / глубины API, который вы пытаетесь обернуть.

Если он имеет всего несколько простых вызовов API, первый подход подходит.

Если у него ОЧЕНЬ сложные API-интерфейсы, которые имеют «простой» режим, который вы хотите предоставить пользователю, один шаблон должен иметь основной модуль и подкласс его как Main :: Module :: Simple, который будет оборачивать основной модуль .

Как вы заметили, очень широкий API может выиграть от разделения на области с параллельными классами (возможно, наследующими или использующими базовый класс), ответственными за перенос каждой области. Просто убедитесь, что вы нашли все общие черты, чтобы избежать дублирования кода / дизайна.