Я создаю библиотеку PHP для API REST стороннего сайта. Библиотека будет выпущена под соответствующей лицензией FOSS, чтобы другие могли ее использовать. На стороннем сайте есть API-интерфейсы для аутентифицированных и неаутентифицированных запросов. Для аутентифицированных запросов они выбрали OAuth .
Как и в большинстве PHP, не существует единственного лучшего способа работы с OAuth. Пока что я определил несколько реализаций OAuth:
Разнообразие доступных библиотек является проблемой. Основная часть OAuth 1 подписывает запрос . Это означает, что для того, чтобы сделать запрос к REST API, мне нужно пройти через одну из библиотек. Я пытаюсь избежать связывания одной из библиотек OAuth с моим кодом и просто позволяю кодировщикам, которые будут использовать библиотеку, выбирать, какую библиотеку OAuth использовать в своем собственном коде. Я считаю это важным из-за сложности понимания OAuth для некоторых кодеров, и очень важно, чтобы кодер, использующий мою библиотеку, был удобен и знаком с OAuth .
.
Я сделал это, создав интерфейс, предназначенный для обертывания объектов OAuth и представления стандартизированного способа для кода моей библиотеки выполнять подписанные HTTP-запросы. До сих пор я создал поддержку библиотек PECL, PEAR и Zend, с библиотекой oauth-php, следующей в списке. Поскольку API также допускает запросы без аутентификации, я также создал адаптеры для потоков PHP и библиотек HTTP-запросов, которые требуются пакетам PEAR и Zend. (Потоки PHP используются по умолчанию без какой-либо настройки, поскольку они встроены и гарантированно будут доступны.)
Это оказалось нетривиальным трудом и делает код выглядит гораздо более сложным и внушительным, чем он есть на самом деле. Код Just Works (tm), и для этого требуется много волшебства (например, автоматический выбор адаптера HTTP на основе имени класса переданного объекта OAuth; это также позволяет пользователям создавать свои собственные адаптеры без изменения библиотеки).
Я начинаю думать, что может быть лучше связать библиотеку OAuth с моим кодом. OAuth определяется RFC, и все связанные библиотеки реализуют его правильно. Я могу просто попросить пользователя предоставить различные ключи / секреты / токены и выполнить работу самостоятельно, за счет добавления требования полной реализации OAuth , которое пользователь не выбрал . Это большой недостаток, на мой взгляд. Далее, есть вопрос совместимости лицензий. Библиотека, которую я должен выбрать, доступна по очень либеральной лицензии FOSS, хотя я бы предпочел более ограничительную лицензию FOSS для моего собственного кода.
tl; dr: Для библиотеки многократного использования, если я продолжу использовать подключаемые адаптеры HTTP и позволю пользователю решать, какую библиотеку OAuth (или библиотеку HTTP не OAuth) использовать, или я должен выбрать для пользователя и просто связать другую библиотеку со своей?