На выходных команда WP REST API опубликовала предложение объединить конечные точки API для типов контента в WordPress 4.7. Это вторая часть предложения, состоящего из двух частей, в котором инфраструктура для API была объединена с ядром в октябре 2015 года. С тех пор команда работала над полировкой конечных точек контента и внесением изменений в ядро, необходимых для поддержки API.
Конечные точки, предлагаемые для слияния, включают сообщения, комментарии, термины, пользователей, метаданные и управление настройками. Это включает в себя публичный доступ, а также доступ с проверкой подлинности по протоколу OAuth 1. Команда выбрала OAuth 1 вместо более нового протокола OAuth 2, поскольку для 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 Core», — прокомментировал это предложение Джордж Стефанис. «Приходится пинговать сторонний сервер при каждом входе в систему, чтобы проверить недействительность их приложений, не говоря уже о первоначальном подтверждении приложения… для меня это не проходит внутреннюю проверку». Стефанис сказал, что он предпочел бы увидеть что-то похожее на подключаемый модуль Application Password System , который разрабатывается для ядра, поскольку он обеспечивает простой поток для приложений, чтобы запрашивать пароли и возвращать сгенерированные пароли обратно. Он также совместим с устаревшим API XML-RPC.
Ведущий разработчик WordPress Дион Халс прокомментировал, что ему не нравится идея иметь стороннего брокера, но он считает, что пароли приложений будут хуже, чем сложности, которые вносят опции OAuth.
«В конце концов, переход на OAuth обеспечит гораздо лучший опыт разработчиков и пользователей для клиентов API», — сказал Халс. «В идеальном мире центральный поставщик не был бы нужен, но у нас пока нет децентрализованной платформы для WordPress, поэтому нет другого механизма, с помощью которого WordPress могла бы сообщать информацию, которую им нужно знать».
Руководитель проекта WordPress Мэтт Малленвег прокомментировал это предложение, назвав проблемы аутентификации основной причиной, по которой он не поддерживает объединение конечных точек в 4.7.
«Учитывая трудности аутентификации, я не думаю, что включение этого в ядро даст преимущества для WP, помимо того, что сообщество получает от плагина», — сказал Малленвег. «Я не верю, что в его нынешнем состоянии выгода перевешивает затраты, и мы должны ошибаться в сторону простоты».
Малленвег также не был убежден, что аутентификация через посредника — лучший способ решить проблемы с OAuth.
«Я не заинтересован в размещении централизованного сервера аутентификации через посредника на WordPress.org в период времени 4.8 и не сомневаюсь в том, какие последствия это имеет для WP в более широком смысле», — сказал он. «Я ценю мысль, которая была вложена в решение этой сложной проблемы».
Предложение открыто для комментариев, и команда WP REST API приветствует отзывы в канале #core-restapi Slack. Они особенно заинтересованы в получении отзывов о безопасности подключаемого модуля REST API и подключаемого модуля OAuth , которые доступны на WordPress.org. Если конечные точки будут объединены, команда планирует реализовать обратную связь в течение следующих нескольких недель, прежде чем 4.7 выйдет в начале декабря.
«В течение оставшихся частей этого цикла выпуска и вплоть до цикла 4.8 дополнительная работа будет выполняться в других частях API», — сказал МакКью. «Это включает в себя дальнейшую работу и доработку системы аутентификации брокера, в том числе работу над инфраструктурой WordPress.org. Кроме того, мы планируем продолжить работу над конечными точками Management API, включая конечные точки темы и внешнего вида, для поддержки команды Customizer».
Команда наметила итеративный подход, который не будет включать полное покрытие wp-admin при слиянии с 4.7, спорный камень преткновения, по которому участники разделились, когда обсуждали возможность слияния конечных точек ранее в этом году . Они предлагают, чтобы конечные точки API управления и конечные точки темы/внешнего вида сохранялись как отдельные проекты функций на GitHub, пока они не будут готовы к слиянию. Разработка, связанная с конечными точками контента, переместится с GitHub на Trac, если слияние будет одобрено.
