Ціль API REST?

Перш за все, я розумію, що це плагін на даний момент, але це, звичайно, майже частина WordPress. Тож я сподіваюсь, що це не позначається як поза темою.

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

Врахуйте це:

Зараз я працюю над коментарями. Я хочу, щоб розділ коментарів завантажувався лише тоді, коли користувач прокручує до розділу коментарів (зі зміщенням -200px, щоб не було затримок) .

• Я збираюся викликати Ajax дзвінок, коли користувач прокручує до цього моменту
• Виклик Ajax надсилає разом із ним деякі дані, наприклад, post_id тощо
• Запустити WP_Comment_Query()на сервері
• Надіслати JSONдані назад клієнту з коментарями відносин, імена, зміст і т.д.
• Використання JavaScript document.createElement(), і innerHTML т.д. для створення і виведення коментарів

Тепер .. Навіщо я використовував REST API замість цього? Яка користь для мене? Просто захищений від майбутнього?

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

У його нинішньому стані це погано спроектована функція, яка не має реальної переваги для компетентного розробника.

Основна ідея, яка стоїть під час написання цієї відповіді, полягає у викритті основних функцій WordPress як API JSON REST. Це дасть змогу роз’єднати логіку WordPress "ділової" з інтерфейсу користувача та дасть змогу створювати різні повні або часткові інтерфейси для управління та отримання інформації з wordpress. Це само по собі не революція, а еволюція. просто заміна API XML-RPC, який сам по собі впорядковує HTTP на основі API подання.

Як і в будь-якій еволюції, на кожному кроці ви можете запитати себе, яку перевагу ви отримуєте від колишнього штату, і відповідь, ймовірно, "не сильно", але, сподіваємось, кроки накопичуються до великої різниці.

То чому ж негативна передмова до цієї відповіді? Оскільки мій досвід як розробник програмного забезпечення полягає в тому, що рідко можливо створити загальний API, який насправді корисний, не маючи конкретних випадків використання для відповіді. Конкретним випадком використання тут може бути заміна API XML-RPC для автоматизованого управління Wordpress, але будь-який пов'язаний передній кінець повинен бути специфічним для сайту, і оскільки існує величезна штрафна ефективність за кожен запит, надісланий клієнтом на сервер, ви не можете просто сукупне використання різних API, щоб отримати бажаний результат таким чином, щоб користувачі залишалися задоволеними. Це означає, що для переднього кінця, для нетривіального використання, все ще буде дуже мала різниця в зусиллях по розробці між використанням маршруту AJAX та маршруту REST-API.

Дві головні переваги:

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

Що стосується вашого прикладу,

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

Ну, насправді кілька речей.

1. Це дозволяє запускати конкретні функції за потребою, а не вимагати всього обчислення завантаження цілої сторінки. Отже, ви можете періодично оновлювати коментарі з досить низькими накладними витратами, не потребуючи оновлення сторінки, просто зателефонувавши до цієї кінцевої точки API та оновивши дані на своїй сторінці. Ця концепція в кінцевому підсумку буде екстраполірована в SPA (додатки для однієї сторінки), які завантажують сайт "клієнт" швидко один раз і емулюють усі "зміни" на сторінці, не потребуючи кожного разу повторно перетягувати HTML-код сторінки. Це вже дуже популярно з появою рамок, таких як Angular, Ember та React. Сайти можуть реагувати зі спалахуючою швидкістю, одночасно завантажуючи деяку обчислювальну потужність для кінцевого споживача (цикл візуалізації, не бізнес-логіка) та зменшуючи загальну кількість дзвінків на сервер (лише тягніть потрібні вам дані,

2. Він розділяє ділову логіку та рендерінг. Так, ви можете використовувати API з іншим сайтом PHP, виплюнувши результати, або обробити його Javascript, як ви згадали, але ви також можете споживати його за допомогою нативного мобільного додатка, настільних додатків тощо. Не тільки це, але ви могли б мати кожен з них спілкується з тим самим API, який послідовно виконує ту саму логіку бізнесу, що, в свою чергу, створює послідовність та надійність для різних клієнтів, що споживають API.

API хороші тим, що вони розділяють питання логіки та відображення.

API WordPress REST - це нова гарячість. Завдяки програмам, що керуються однією сторінкою, і WordPress бажає стати платформою додатків, це має багато сенсу. План полягає в заміні XML-RPC на API REST (що добре тільки з міркувань безпеки!)

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

• Мабуть, на ньому створений новий сайт Нью-Йоркського часу .
• Це дозволяє мобільним додаткам та іншим зовнішнім службам отримувати доступ до вмісту wp (наприклад, wp-cli )
• Це дозволяє розробникам створити передповерховий додаток на одній сторінці із улюбленою програмою JSON, що споживає тиждень, і мати усі цікаві взаємодії під рукою.
• Це дозволяє розділити питання (як уже згадувалося вище) та підвищити незалежність між бек-ендом і передньою командою.

Це ще один набір інструментів для просування WordPress вперед. І хоча це було хиткою подорожжю, щоб дістатися до того, де ми є, я думаю, що варто витратити час на його вивчення та розуміння.

Перш за все - REST - це легка вага

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

Ви цього не хочете?

На додаток до згаданих 2 чудових моментів @Milo, я спеціально використовую API REST для викриття своїх даних для програм, що не входять в WordPress. У нас є розширення для Chrome, яке витягує інформацію з нашої бази даних WordPress, і це здійснюється шляхом потрапляння на кінцеві точки API REST із запитами 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? Я не впевнений, де документація. О ... був дзвінок в Аяксі 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 або будь-яка інша технологія. Я просто хочу створити новий Віджет.

API REST розв'язує серверну частину спереду. Технічно, якщо ваш API достатньо хороший, ви можете змінити весь стек заходу. Поки ви підтримували ту саму структуру API REST, все, що залежало від API, не вплине.

Якщо ваш API REST досить простий і послідовний, використовуючи іменник, як Widgetsнабір об’єктів і іменник / ідентифікатор, як, Widget/2щоб позначити одну сутність, написати цей API в абсолютно іншій технології, тому що це більш-менш основна сантехніка баз даних код.

Використовує стандартні дієслова HTTP Request.

API REST використовує серцевину роботи веб-сторінок та VERB (читати: дія), які ви використовуєте map для стандартних функцій CRUD даних.

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

Є більше дієслів HTTP, але це основи. Кожен окремий запит через Інтернет використовує ці дієслова. API REST розташовується прямо на верхній частині моделі, побудованої в Інтернеті за запитами. Немає необхідності в будь-якому комунікаційному шарі чи моделі абстрагування між ними. Це просто стандартний запит http до URL, і він повертає відповідь. Ви не можете отримати набагато простіше, ніж це.

По суті, це робить розробника більш обізнаним із гайками та болтами того, як веб-сайт насправді працює, і коли ви ближче розумієте, як працюють основні протоколи, ви в кінцевому підсумку робите більш ефективний, кращий продукт.