Цель API REST?

Прежде всего, я понимаю, что на данный момент это плагин, но, в любом случае, он почти наверняка является частью WordPress. Поэтому я надеюсь, что это не будет помечено как не по теме.

Я читал их официальные документы, много других статей и смотрел обучающие видео, но я все еще не получил некоторые из пунктов ... Это, безусловно, будущее WordPress, это очень удобно для разработки мобильных приложений и использования / обмена данными между разные сайты, но: что это делает только для моего сайта?

Учти это:

Сейчас я работаю над комментариями. Я хочу, чтобы секция комментариев загружалась только тогда, когда пользователь прокручивает секцию комментариев (со смещением -200px, чтобы не было задержки) .

• Я собираюсь вызвать AJAX-вызов, когда пользователь прокручивает до этой точки
• Ajax вызова отправляет некоторые данные с ним, как и post_id т.д.
• Запустить WP_Comment_Query()на сервере
• Отправить JSONданные обратно клиенту с комментариями, именами, контентом и т. Д.
• Используйте JavaScript document.createElement()и innerHTML т. Д. Для создания и вывода комментариев

Теперь ... Почему бы вместо этого использовать REST API? Какая польза для меня? Просто будущее?

Я бы все - таки нужно использовать JavaScript для вывода всех данных , которые я получаю .. я не нашел каких - либо хороших статей , почему или за то , что я должен использовать REST API ( за исключением передачи данных между сайтами и мобильных приложений) Развитию ..

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

На момент написания этого ответа основная идея состоит в том, чтобы представить основные функциональные возможности WordPress как JSON REST API. Это позволит отделить бизнес-логику WordPress от пользовательского интерфейса и позволит создавать различные полные или частичные пользовательские интерфейсы для управления и извлечения информации из WordPress. Само по себе это не революция, а эволюция. просто замена API-интерфейса XML-RPC, который сам по себе оптимизирует HTTP на основе API представления.

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

Так почему же отрицательное предисловие к этому ответу? Потому что мой опыт работы в качестве разработчика программного обеспечения заключается в том, что редко можно разработать общий API, который на самом деле полезен, не имея конкретных вариантов использования для ответа. Конкретным вариантом использования здесь может быть замена XML-RPC API для автоматического управления WordPress, но любой связанный с ним интерфейс должен быть специфичным для сайта, и, поскольку существует огромный ущерб производительности для каждого запроса, отправляемого с клиента на сервер, вы не можете просто совокупное использование различных API для получения желаемого результата таким образом, чтобы пользователи остались довольны. Это означает, что для внешнего интерфейса, для нетривиального использования, все еще будет очень мало различий в усилиях по разработке между использованием маршрута AJAX и маршрута REST-API.

Два главных преимущества:

1. Вы можете (в конце концов) выполнять все задачи администратора без интерфейса администратора.
2. Вы можете получить все данные для отображения и полностью исключить интерфейс (и писать PHP).

Что касается вашего примера конкретно

Замените шаги 3 и 4 на REST API, а шаги 1, 2 и 5 замените Backbone.js. БУМ, динамическое веб-приложение. Или, может быть, вам удобнее выполнять сложную маршрутизацию, необходимую для вашего сайта, с помощью Python.

Ну, несколько вещей на самом деле.

1. Это позволяет вам запускать определенные функции по мере необходимости, вместо того, чтобы требовать все вычисления всей загрузки страницы. Таким образом, вы можете периодически обновлять комментарии с довольно низкими издержками без необходимости обновления страницы, просто вызывая эту конечную точку API и обновляя данные на вашей странице. Эта концепция в конечном итоге будет экстраполирована на SPA (одностраничные приложения), которые один раз быстро загружают «клиентский» сайт и эмулируют все «изменения» страницы без необходимости каждый раз повторять HTML-код страницы. Это уже очень популярно с появлением таких фреймворков, как Angular, Ember и React. Сайты могут реагировать с молниеносной скоростью, в то же время одновременно передавая некоторую вычислительную мощность конечному пользователю (цикл рендеринга, не бизнес-логика) и значительно сокращая общее количество обращений к серверу (извлекайте только те данные, которые вам нужны,

2. Он разделяет бизнес-логику и визуализатор. Да, вы можете использовать API с другим сайтом PHP, выплевывая результаты, или обрабатывать его с помощью Javascript, как вы упомянули, но вы также можете использовать его с собственным мобильным приложением, настольным приложением и т. Д. Не только это, но вы могли бы иметь каждый из них использует один и тот же API, который последовательно выполняет одну и ту же бизнес-логику, что, в свою очередь, создает согласованность и надежность для различных клиентов, использующих API.

API хороши тем, что разделяют проблемы логики и отображения.

WordPress REST API - это новинка. С одностраничными приложениями, управляемыми js, и желанием WordPress стать платформой приложений это имеет большой смысл. План состоит в том, чтобы заменить XML-RPC на REST API (что хорошо только по соображениям безопасности!)

https://make.wordpress.org/core/2015/09/21/wp-rest-api-merge-proposal/

• Судя по всему, на нем построен новый сайт времен Нью-Йорка .
• Это позволяет мобильным приложениям и другим внешним службам получать доступ к wp-контенту (например, wp-cli ).
• Это позволяет разработчикам создавать одностраничный интерфейс приложения с их любимой платформой JSON, потребляющей всю неделю, и иметь в своем распоряжении все классные взаимодействия.
• Это позволяет разделить проблемы (как упомянуто выше) и большую независимость между бэкэнд-командой и командой переднего плана.

Это еще один набор инструментов для продвижения WordPress. И хотя это было извилистое путешествие, чтобы добраться туда, где мы находимся, я думаю, что стоит потратить время, чтобы исследовать и понять его.

Перво-наперво - REST - это легкий

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

Ты этого не хочешь?

В дополнение к двум замечательным моментам, о которых упоминал @Milo, я специально использую REST API для предоставления своих данных приложениям, не относящимся к WordPress. У нас есть расширение Chrome, которое извлекает информацию из нашей базы данных WordPress, и это достигается путем попадания в конечные точки REST API запросов POST.

УСТОЙЧИВАЯ Инфраструктура

API REST является последовательным и понятным для человека. Это самодокументирование.

GET wp-json/wp/v2/postsдовольно ясно, что он делает. Это GETнесколько постов.

У вас есть пространство имен:, wpверсия: v2и коллекция объектовposts

Можете ли вы угадать, что: GET wp-json/wp/v2/posts/5делает? Как насчет: GET wp-json/wp/v2/posts/5/comments Как насчет:GET wp-json/shop/v2/orders/345/lines/11/price

Глядя на это, разработчик может легко догадаться, что он получит цену линии 11при заказе, 345даже не читая документацию. Разработчик даже может легко сказать, что он исходит от shopплагина, так как он находится в пространстве имен.

Как насчет POST /wp-json/v2/posts title=New Blog Post Как насчетPUT /wp-json/v2/posts title=New Title

Это тоже довольно ясно. Это делает новый пост. Кстати, он возвращает идентификатор нового поста. Это не про AJAX ИЛИ REST API. AJAX - это просто технология доступа к REST API. Принимая во внимание, прежде, вам придется придумать кучу абстрактных АЯКС имен функций , таких как: get_price_for_lineitem( $order, $line ). Это будет возвращать только число или объект JSON? Я не уверен, где находится документация. Ох ... был вызов Ajax get_order_line_priceили get_lineitem_price.

Разработчик не должен принимать эти решения, потому что существующий wp-jsonAPI предоставляет хорошую базовую модель, которой нужно следовать при создании ваших собственных конечных точек. Конечно, разработчик плагинов или API может нарушить эти правила, но в целом легче следовать стандарту, который уже установлен, и большинство разработчиков предпочли бы следовать уже установленному шаблону (посмотрите, насколько распространены сейчас шаблоны jQuery).

Абстракция без отвлечения

Я забочусь о том, как POST /wp-json/mysite/v1/widgets title=Foobarработает? Нет. Я просто хочу создать новый Widgetи хочу получить взамен идентификатор. Я хочу сделать это из формы на моем внешнем интерфейсе, не обновляя страницу. Если я делаю запрос к URL, мне все равно, PHP это, C #, ASP.NET или какая-либо другая технология. Я просто хочу создать новый виджет.

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

Если ваш REST API достаточно простой и непротиворечивый, с использованием существительного, такого Widgetsкак набор объектов, и существительного / идентификатора, например, Widget/2для обозначения единого объекта, действительно просто написать этот API в совершенно другой технологии, так как это более или менее базовая схема базы данных. код.

Использует стандартные глаголы HTTP Request.

API REST используют ядро ​​работы сети и VERB (читай: действие), которые вы используете, для сопоставления со стандартными функциями CRUD для данных.

CREATE : POST
READ   : GET
UPDATE : PUT/PATCH
DELETE : DELETE

Есть больше HTTP-глаголов, но это основы. Каждый запрос через Интернет использует эти глаголы. REST API находится прямо над моделью, в которой сеть строится по запросам. Нет необходимости в каком-либо уровне коммуникации или модели абстракции между ними. Это просто стандартный http-запрос к URL, который возвращает ответ. Вы не можете получить намного проще, чем это.

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