Cel interfejsu API REST?

Po pierwsze, rozumiem, że jest to wtyczka w chwili obecnej, ale z pewnością jest prawie częścią WordPress. Mam więc nadzieję, że nie jest to oznaczane jako nie na temat.

Przeczytałem ich oficjalne dokumenty, wiele innych artykułów i obejrzałem filmy instruktażowe, ale nadal nie dostaję niektórych punktów. To z pewnością przyszłość WordPress, jest bardzo przydatna do tworzenia aplikacji mobilnych i używania / udostępniania danych między różne witryny, ale: co to robi tylko dla mojej witryny?

Rozważ to:

Obecnie pracuję nad komentarzami. Chcę, aby sekcja komentarzy była ładowana tylko wtedy, gdy użytkownik przewija do sekcji komentarzy (z przesunięciem -200px, aby nie było opóźnień) .

• Wywołam wywołanie ajax, gdy użytkownik przewinie do tego punktu
• Wywołanie Ajax wysyła z nim niektóre dane, takie jak post_id itp
• Uruchom WP_Comment_Query()na serwerze
• Odeślij JSONdane do klienta z komentarzami, nazwami, treścią itp
• Zastosowanie JavaScript document.createElement(), innerHTML etc do tworzenia i komentarze wyjściowe

Teraz .. Dlaczego zamiast tego miałbym używać interfejsu API REST? Jaki jest pożytek dla mnie? Po prostu przyszłościowy?

Nadal będę musiał używać JavaScript do wyświetlania wszystkich danych, które otrzymuję. Nie znalazłem żadnych dobrych artykułów, dlaczego lub do czego powinienem używać REST API (oprócz przesyłania danych między stronami i tworzenia aplikacji mobilnych) ..

W obecnym stanie jest to źle zaprojektowana funkcja, która nie ma żadnej realnej korzyści dla kompetentnego programisty.

Podstawową ideą w chwili pisania tej odpowiedzi jest ujawnienie podstawowej funkcjonalności WordPress jako JSON REST API. Umożliwi to oddzielenie logiki „biznesowej” WordPress od interfejsu użytkownika i umożliwi tworzenie różnych pełnych lub częściowych interfejsów użytkownika w celu zarządzania i wydobywania informacji z wordpress. To samo w sobie nie jest rewolucją, ale ewolucją. po prostu zamiana interfejsu API XML-RPC, który sam w sobie usprawnia HTTP oparty na interfejsie API przesyłania.

Jak w przypadku każdej ewolucji, na każdym kroku możesz zadać sobie pytanie, jaką korzyść uzyskujesz z poprzedniego stanu, a odpowiedź brzmi prawdopodobnie „niewiele”, ale mam nadzieję, że kroki te kumulują się do dużej różnicy.

Dlaczego więc przecząca wstęp do tej odpowiedzi? Ponieważ moje doświadczenie jako programisty polega na tym, że rzadko jest możliwe zaprojektowanie ogólnego interfejsu API, który jest faktycznie przydatny bez konkretnych przypadków użycia, na które można by odpowiedzieć. Konkretnym przykładem użycia może być zastąpienie interfejsu API XML-RPC do zautomatyzowanego zarządzania wordpressem, ale wszelkie powiązane interfejsy muszą być specyficzne dla witryny, a ponieważ za każde żądanie wysłane z klienta na serwer istnieje ogromna obniżka wydajności, nie można po prostu łączne użycie różnych interfejsów API w celu uzyskania pożądanego rezultatu w taki sposób, aby użytkownicy byli zadowoleni. Oznacza to, że w przypadku interfejsu użytkownika, w przypadku nietrywialnego użycia, nadal będzie bardzo niewielka różnica w nakładach programistycznych między użyciem trasy AJAX i trasy REST-API.

Dwie nadrzędne zalety to:

1. Możesz (ostatecznie) wykonywać wszystkie zadania administracyjne bez interfejsu administratora.
2. Możesz uzyskać wszystkie dane do wyświetlenia i całkowicie wyeliminować interfejs (i pisanie PHP).

Jeśli chodzi konkretnie o twój przykład-

Zastąp kroki 3 i 4 interfejsem API REST, a kroki 1, 2 i 5 zamień na Backbone.js. BOOM, dynamiczna aplikacja internetowa. A może wygodniejsze jest wykonywanie skomplikowanego routingu niezbędnego dla Twojej witryny za pomocą Pythona.

Właściwie to kilka rzeczy.

1. Umożliwia uruchamianie określonych funkcji w zależności od potrzeb, zamiast wymagać całego obliczenia ładowania całej strony. Tak więc możesz okresowo aktualizować komentarze z dość niskim narzutem, bez konieczności odświeżania strony, po prostu wywołując ten punkt końcowy interfejsu API i aktualizując dane na stronie. Ta koncepcja zostanie ostatecznie ekstrapolowana na OSO (aplikacje jednostronicowe), które szybko ładują stronę „klienta” i emulują wszystkie „zmiany” strony bez konieczności ponownego pobierania kodu HTML strony za każdym razem. Jest to już bardzo popularne wraz z pojawieniem się frameworków takich jak Angular, Ember i React. Witryny mogą błyskawicznie reagować, jednocześnie obciążając użytkownika końcowego pewną mocą obliczeniową (cykl renderowania, logika pozabiznesowa) i znacznie zmniejszając ogólną liczbę połączeń z serwerem (pobierając tylko potrzebne dane,

2. Oddziela logikę biznesową i mechanizm renderujący. Tak, możesz używać interfejsu API z inną witryną PHP i wyrzucać wyniki, lub obsługiwać JavaScript, tak jak wspomniałeś, ale możesz także używać go z natywną aplikacją mobilną, aplikacją komputerową itp. Nie tylko, ale możesz mieć każdy z nich rozmawia z tym samym interfejsem API, który konsekwentnie realizuje tę samą logikę biznesową, co z kolei zapewnia spójność i niezawodność dla różnych klientów korzystających z interfejsu API.

Interfejsy API są dobre, ponieważ rozdzielają problemy związane z logiką i wyświetlaniem.

Interfejs API REST WordPress to nowa popularność. Z aplikacjami opartymi na jednostronicowej js, a WordPress chce stać się platformą aplikacji, ma to sens. Plan polega na zastąpieniu XML-RPC interfejsem API REST (co jest dobre ze względów bezpieczeństwa!)

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

• Najwyraźniej zbudowano na nim nową witrynę z czasów Nowego Jorku .
• Pozwala aplikacjom mobilnym i innym usługom zewnętrznym na dostęp do treści wp (takich jak wp-cli )
• Pozwala programistom na tworzenie jednostronicowego interfejsu aplikacji z ulubionym środowiskiem JSON tygodnia i zapewnia wszystkie fajne interakcje na wyciągnięcie ręki.
• Pozwala to na rozdzielenie obaw (jak wspomniano powyżej) i większą niezależność między zespołami zaplecza i frontonu.

To kolejny zestaw narzędzi, które posuwają WordPress do przodu. I choć podróż do miejsca, w którym się znajdujemy, była kręta, uważam, że warto poświęcić czas na jej zbadanie i zrozumienie.

Po pierwsze - REST jest lekki

W jednym wierszu - Kiedy używamy interfejsów API REST, wykonujemy wszystkie renderowanie danych po stronie klienta (pętle, warunki i wywołania po stronie serwera itp.), Oszczędzając przepustowość, a jednocześnie nasza aplikacja jest gotowa na dowolną platformę mobilną, integrację z innymi firmami i zmodularyzowana ( rozróżnienie między frontendem a serwerem).

Nie chcesz tego?

Oprócz wspomnianych 2 świetnych punktów @Milo, szczególnie używam interfejsu API REST, aby udostępnić moje dane aplikacjom innym niż WordPress. Mamy rozszerzenie Chrome, które pobiera informacje z naszej bazy danych WordPress, a osiąga się to poprzez uderzanie punktów końcowych interfejsu API REST za pomocą żądań POST.

KONSEKWENTNA Infrastruktura

Interfejs API REST jest spójny i czytelny dla człowieka. To jest samodokumentowanie.

GET wp-json/wp/v2/postsjest całkiem jasne, co robi. To GETsą niektóre posty.

Masz przestrzeń nazw:, wpwersję: v2i kolekcję obiektówposts

Czy wiesz, co: GET wp-json/wp/v2/posts/5robi? Co powiesz na: Co GET wp-json/wp/v2/posts/5/comments powiesz na:GET wp-json/shop/v2/orders/345/lines/11/price

Deweloper może łatwo zgadnąć, patrząc na to, że dostanie cenę linii 11na zamówienie, 345nawet bez czytania dokumentacji. Dev może nawet łatwo stwierdzić, że pochodzi z shopwtyczki, ponieważ ma przestrzeń nazw.

Co powiesz POST /wp-json/v2/posts title=New Blog Post na?PUT /wp-json/v2/posts title=New Title

To też całkiem jasne. To sprawia, że ​​nowy post. Nawiasem mówiąc, zwraca identyfikator nowego postu. Nie chodzi o AJAX LUB interfejs API REST. AJAX to po prostu technologia, która uzyskuje dostęp do interfejsu API REST. Zważywszy, że wcześniej trzeba by wymyślić bandą abstrakcyjnych ajax nazw funkcji, takich jak: get_price_for_lineitem( $order, $line ). Czy to zwróci tylko liczbę, czy obiekt JSON? Nie jestem pewien, gdzie jest dokumentacja. Och ... było wywołanie ajax get_order_line_pricelub get_lineitem_price.

Deweloper nie musi podejmować tych decyzji, ponieważ istniejący wp-jsoninterfejs API zapewnia dobry model podstawowy do naśladowania podczas tworzenia własnych punktów końcowych. Oczywiście, twórca wtyczki lub interfejsu API może złamać te reguły, ale ogólnie łatwiej jest przestrzegać standardu, który już został ustawiony, a większość programistów wolałaby raczej postępować zgodnie z już ustalonym wzorcem (zobacz, jak teraz są wszechobecne wzorce jQuery).

ABSTRAKCJA bez rozpraszania uwagi

Czy zależy mi na tym, jak to POST /wp-json/mysite/v1/widgets title=Foobardziała? Nie. Chcę tylko utworzyć nowy Widgeti chcę w zamian identyfikator. Chcę to zrobić z formularza na moim interfejsie bez odświeżania strony. Jeśli poproszę o adres URL, nie dbam o to, czy jest to PHP, C #, ASP.NET lub inna technologia. Chcę tylko utworzyć nowy widżet.

Interfejs API REST oddziela backend od przodu. Technicznie, jeśli twój interfejs API jest wystarczająco dobry, możesz zmienić cały stos backendu. Tak długo, jak utrzymasz tę samą strukturę interfejsu API REST, nie będzie to miało wpływu na wszystko, co zależało od interfejsu API.

Jeśli interfejs API REST jest wystarczająco prosty i wystarczająco spójny, używając rzeczownika podobnego Widgetsdo zbioru obiektów i rzeczownika / identyfikatora Widget/2wskazującego pojedynczy byt, naprawdę łatwo jest napisać ten interfejs API w zupełnie innej technologii, ponieważ jest to mniej więcej podstawowa hydraulika bazy danych kod.

Używa standardowych czasowników żądania HTTP.

Interfejsy API REST wykorzystują rdzeń działania sieci oraz VERB (czytaj: akcja), których używasz odwzorować na standardowe funkcje CRUD danych.

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

Jest więcej czasowników HTTP, ale to są podstawy. Każde pojedyncze żądanie przez Internet używa tych czasowników. Interfejs API REST znajduje się bezpośrednio nad modelem, który jest budowany na żądanie. Nie ma potrzeby stosowania żadnej warstwy komunikacyjnej ani modelu abstrakcji pomiędzy nimi. To tylko standardowe żądanie HTTP do adresu URL i zwraca odpowiedź. Nie można uzyskać dużo prostszego niż to.

Zasadniczo sprawia, że ​​programiści są bardziej świadomi faktycznych zasad działania sieci, a gdy zbliżasz się do zrozumienia, w jaki sposób działają protokoły bazowe, tworzysz skuteczniejszy, lepszy produkt.