Вчера команда WP REST API встретилась на канале Slack #core-restapi, чтобы обсудить статус существующих конечных точек публикации, термина, пользователя и комментария. Есть несколько нерешенных проблем с этими четырьмя основными объектами, которые команда хочет решить с помощью подхода с функциональными плагинами вместо того, чтобы удерживать API от слияния. Эти выдающиеся элементы включают в себя такие вещи, как защищенные паролем сообщения, автосохранение и предварительный просмотр сообщений, а также метаобработка.
«На данный момент мы не собираемся их поддерживать и вместо этого будем работать над ними в отдельном функциональном плагине», — сказал руководитель проекта WP REST API Райан МакКью . «Опять же, это будет усовершенствованием API в будущем и не блокирует совместимость здесь».
В сентябре 2015 года МакКью и его участники наметили план слияния для REST API , который перенес инфраструктуру в выпуск 4.4 с конечными точками на палубе, чтобы последовать за одним выпуском позже в 4.5. Участники REST API считают, что проект все еще находится на пути к достижению этой цели.
«Наше предложение состоит в том, чтобы мы объединили четыре основных объекта в REST API с полной поддержкой чтения, создания, обновления и удаления, а дополнительные периферийные функции появятся, когда они будут готовы», — сказал МакКью.
Несколько участников WordPress, в том числе руководитель проекта Мэтт Малленвег, выразили обеспокоенность по поводу доставки REST API без функций, которые были временно выделены.
«Я знаю, что это мнение меньшинства, но я бы довольно скептически отнесся к объединению частичного API с ядром», — сказал Малленвег. «Я думаю, что это принесет гораздо больше вреда, чем пользы».
МакКью утверждал, что команда работала над выпуском продукта, который можно было бы постепенно улучшать.
«API специально структурирован для прогрессивного улучшения, что является ключевым отличием от многих API», — сказал он. «Предоставление клиентам возможности обнаруживать функции и поддерживать их, когда они будут готовы, обеспечивает нам огромную гибкость».
Нужен ли WP REST API полный охват wp-admin?
Аарон Джорбин отметил, что, хотя четыре основных типа объектов позволяют использовать некоторые инновационные темы и редакторы контента, они еще не позволяют полностью заменить wp-admin. Этот конкретный момент стал нарушителем условий сделки для нескольких участников, присутствовавших на встрече.
«Случаи, когда текущий API охватывает сегодня, не очень интересны, потому что они на самом деле не позволяют делать то, что было невозможно сделать раньше», — сказал Мулленвег. «Это просто другой подход к тому, что было возможно раньше. Я даже не думаю, что у нас пока есть паритет XML-RPC в поддержке функций.
«Я бы не включал примеры REST в SoTW, не поощрял плагины к использованию скаффолдинга, и даже не позволял использовать скаффолдинг в последней версии, если бы не считал, что сейчас это самое многообещающее решение», — он сказал. «Но освоение определенно ощущается медленнее, чем я ожидал. Потребовалось так много времени, чтобы добраться до этого момента, и если мы не наберем темп, может пройти еще год или два, прежде чем мы получим полное покрытие wp-admin».
Несмотря на то, что WP REST API недавно провел собственную конференцию , посвященную ему, большинство людей, которые работают с ним, являются теми, кто также участвует в проекте. Принятие еще не получило широкого распространения, но это может быть связано с тем, что многие разработчики не хотят использовать его до тех пор, пока основные конечные точки не будут официально объединены.
«У нас есть что-то вроде курицы и яйца: без основного внедрения потенциальные потребители API не решаются сделать решающий шаг, но без принятия он не будет достаточно протестирован для слияния», — сказал участник REST API К. Адам Уайт. .
«С точки зрения проекта я не очень в восторге от поставки API, который требует «некоторой сборки», по сравнению с выпуском ядра в паре с интересными нетривиальными приложениями-убийцами (мобильными приложениями, чем-то вроде калипсо, большими плагинами, использующими / поддерживая это)», — сказал Мулленвег. «Для меня полный API — это тот, который охватывает все, что возможно в wp-admin. Подмножество этого — частичный API».
Однако несколько участников проекта REST API согласились с тем, что поставка с возможностью полной замены администратора нереалистична, особенно после того, как Mullenweg подтвердил , что он должен поддерживать все возможное в администрировании, включая редактор файлов.
«Мы значительно больше заинтересованы в получении доступа для чтения/записи к основным типам, чтобы мы могли взаимодействовать с WP с множества других платформ», — сказал К. Адам Уайт. «Я думаю, что откладывание всего до тех пор, пока оно не будет «готово к Calpyso», блокирует множество вариантов использования, прежде чем они смогут начать работу».
В ответ Малленвег спросил, почему WordPress должен поддерживать в своем веб-интерфейсе то, что не поддерживается через его официальный API. По завершении двухчасовой встречи он резюмировал свое окончательное предложение: «Никаких частичных конечных точек в ядре. Давайте разработаем полный API, а не наполовину и навяжем его миллионам сайтов», — сказал он.
Это критический момент для проекта WP REST API. В то время как большинство участников, казалось, согласились с дальнейшим повторением существующих конечных точек и увеличением их использования перед их объединением в ядро, участники по-прежнему расходились во мнениях относительно необходимости иметь полное покрытие wp-admin до объединения.
Члены команды WP REST API полностью привержены итерации отдельных периферийных функций, но другой контингент участников WordPress, присоединившийся вчера к собранию, непреклонен в том, чтобы увидеть более совершенный API с лучшей поддержкой администратора. Перспективный план еще не появился.
