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.