WP REST API задерживается, участники зашли в тупик

Команда WP REST API на днях встретилась на Slack-канале #core-restapi, чтобы обсудить статус существующих конечных точек post, term, user и comment. С этими четырьмя базовыми объектами связано несколько вопросов, которые команда хочет решить при помощи подхода с функциональным плагином (что позволит не отказываться от слияния API). Неразрешенные вопросы связаны с записями, защищенными паролем, автосохранениями, превью, а также обработкой мета.

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

В сентябре 2015 года Маккью и остальные участники спроектировали план слияния для REST API, который позволил внести инфраструктуру в релиз WordPress 4.4; следом за ней должны были появиться и конечные точки в WordPress 4.5. Участники REST API считают, что эта цель все еще может быть достигнута.

«Наше предложение заключается в том, что мы вносим четыре базовых объекта в REST API с полной поддержкой чтения, создания, обновления и удаления. При этом все периферийные функции будут внесены по мере их готовности», отметил Маккью.

Некоторые участники WordPress, включая руководителя проекта Мэтта Мулленвега, озвучили свои опасения по поводу поставки REST API с временно отсутствующими функциями.

«Я знаю, что это – мнение меньшинства, но я достаточно скептически отношусь к слиянию части API с ядром», ответил Мулленвег. «Я думаю, что это принесло бы гораздо больше вреда, чем пользы».

Маккью считает, что команда изначально работала над продуктом, который будет прогрессивно улучшаться.

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

Должен ли WP REST API покрывать всю админку?

Аарон Джорбин отметил следующее: несмотря на то, что четыре базовых типа объектов допускают использование некоторых инновационных редакторов тем и контента, они не могут стать полноценной заменой всего wp-admin. Этот момент стал камнем преткновения для группы участников, посетивших встречу.

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

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

Несмотря на то, что по WP REST API недавно прошла отдельная конференция, полностью посвященная этому проекту, большинство людей, работающих с API, являются его активными участниками и разработчиками. Переход к API пока еще не настолько широк, как хотелось бы – многие разработчики не хотят работать с ним, поскольку ждут официального появления конечных точек в ядре.

«Мы столкнулись с некоторой дилеммой: без переноса API в ядро потенциальные пользователи не готовы сделать решающий шаг и перейти к разработке веб-проектов на базе API, однако без создания начальных проектов не получается в достаточной мере протестировать API, чтобы внести его в ядро», говорит участник REST API К. Адам Уайт.

«Я не разделяю восторга по поводу поставки API с урезанным функционалом. Мне лично больше импонирует базовый релиз, совмещенный с нестандартными решениями (мобильными приложениями, напоминающими Calypso, крупными плагинами, которые используют API или поддерживают его), отметил Мулленвег. «Для меня полноценный API – это API, который покрывает абсолютно все аспекты wp-admin. Какое-либо подмножество его – это лишь частичный API».

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

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

В ответ на это Малленвег спросил, почему система WordPress должна поддерживать что-то в своем веб-интерфейсе,  что не поддерживает ее официальный API. В конце двухчасовой встречи Мэтт сформулировал свое окончательное предложение: «Никаких частичных конечных точек в ядре. Давайте разрабатывать законченный API, который можно будет передать миллионам сайтов, а не какой-то огрызок».

Проект WP REST API находится в своей критической точке. В то время как большинство участников согласились с последующей доработкой существующих конечных точек и наращиванием использования API перед внесением его в ядро, присутствующие лица на конференции разделились во мнениях по поводу того, на чем нужно сделать акцент: на полном охвате wp-admin или на слиянии API с ядром.

Участники команды WP REST API придерживаются подхода с итеративным улучшением периферийных функций, однако остальные присутствующие на встрече считают, что сначала нужно доработать API и усовершенствовать поддержку wp-admin. Консенсус пока не найден.