В прошлые выходные команда WP REST API опубликовала предложение о внесении конечных точек API для типов контента в WordPress 4.7. Это представляет собой второй шаг из двухэтапного предложения по внесению инфраструктуры для API в ядро. Базовое предложение  было опубликовано еще в октябре 2015. С тех пор команда активно трудилась над улучшением произвольных конечных точек, внося изменения, необходимые для поддержки API.

Конечные точки, предложенные для слияния, включают в себя записи, комментарии, термы, пользователей, метаданные, а также параметры. Также предложен публичный доступ и аутентифицированный доступ по протоколу OAuth 1. Команда выбрала OAuth 1, а не более свежий OAuth 2, поскольку последний требует HTTPS с современной версией TLS. А так как ядро WordPress не требует HTTPS, команда не стала делать это требованием для использования API.

«В предложении по слиянию представлен полноценный, функциональный Content API, обеспечивающий все необходимые конечные точки для мобильных приложений и фронтэндов, а также закладывающий фундамент для последующих релизов, сфокусированных на формировании интерфейса Management API для администрирования всего сайта», отметил Райан Маккью в предложении, опубликованном от лица команды WP REST API.

Обратная связь в комментариях показала, что автор поддерживают слияние API. Лишь несколько участников WordPress выразили свою озабоченность по поводу выбранной схемы аутентификации. Сайты на WordPress не имеют централизованного OAuth сервера, что означает, что тем, кто использует API для создания приложений, понадобится регистрировать их на каждом отдельном WordPress-сайте. Чтобы избежать этого, команда WP REST API создала посредническую схему аутентификации с основной брокерской системой, доступной по адресу apps.wp-api.org. Команда предложила внести брокерскую аутентификацию в WordPress 4.8 с целью лучшего тестирования. В конце концов, брокер будет размещен на WordPress.org.

«Концепция стороннего брокера является совершенно чуждой для ядра WordPress», отметил Джордж Стефанис в комментариях к предложению. «Постоянно пинговать сторонний сервер для каждого входа, чтобы проверить инвалидацию приложений, не говоря уже о базовом подтверждении приложения… как по мне, так это не самый лучший вариант». Стефанис отметил, что он предпочел бы видеть что-то похожее на функциональный плагин Application Password System, который разрабатывается для ядра и который обеспечивает простой способ запроса паролей для приложений и получения сгенерированных паролей обратно. Он также совместим с XML-RPC API.

Ведущий разработчик WordPress Дион Халс отметил, что ему не нравится идея наличия стороннего брокера, но считает, что Application Passwords будет хуже, чем внедрение возможностей OAuth.

«В конце концов, движение в сторону OAuth позволит обеспечить гораздо лучший опыт разработки и взаимодействия для клиентов API», отметил Халс. «В идеале, конечно, лучше обходиться без центрального провайдера, но у нас нет децентрализованной платформы для WordPress в данный момент».

Мэтт Мулленвег прокомментировал предложение, сославшись на проблемы аутентификации как на базовую причину того, почему он выступает против внесения конечных точек в версию 4.7.

«Учитывая препятствия с аутентификацией, я не думаю, что внесение всего этого в ядро принесет преимущества для WP кроме тех, что сообщество уже может получить, воспользовавшись плагином», отметил Мулленвег. «Я не думаю, что на данном этапе выгода этого шага так существенна, а потому лучше поддержим простоту».

Мулленвег также сомневается в том, что брокерская аутентификация является лучшим способом решения проблем, связанных с OAuth.

«Я не заинтересован в размещении централизованного сервера брокерской аутентификации на WordPress.org для релиза 4.8, и вообще меня терзают смутные сомнения по поводу последствий этого шага для WP в более широком плане», отметил Мэтт. «Однако я ценю тот способ, который нашли разработчики для решения этой непростой проблемы».

Предложение открыто для комментариев, и команда WP REST API приветствует любую обратную связь на Slack канале #core-restapi. В частности, команда заинтересована в получении обратной связи по поводу безопасности плагина REST API и плагина OAuth, которые доступны на WordPress.org. Если конечные точки войдут в ядро, команда планирует проанализировать поступившие предложения и реализовать некоторые из них в течение нескольких недель перед тем, как выйдет релиз 4.7 (выход запланирован на начало декабря).

«Мы планируем проработать и другие участки API в пределах текущего релиз-цикла и в цикле 4.8», отметил Маккью. «Мы будем улучшать и оттачивать систему брокерской аутентификации, совершенствуя инфраструктуру WordPress.org. Также мы планируем продолжить работу над конечными точками Management API, включая конечные точки для тем и внешнего вида, которые требуются команде по разработке кастомайзера».

Команда изложила итеративный подход, который не будет включать в себя полное покрытие всего wp-admin при внедрении в релиз 4.7 – достаточно спорный подход, который разделил всех участников на два противоборствующих лагеря в начале этого года. Команда пришла к выводу, что конечные точки Management API и конечные точки для тем/внешнего вида будут поддерживаться в виде отдельных проектов на GitHub, пока они не будут готовы для слияния с ядром. Разработка, связанная с конечными точками для контента, в случае одобрения слияния будет перенесена с GitHub в Trac.

Источник: wptavern.com