The REST API is consistent and human-readable. It's self-documenting.
GET wp-json/wp/v2/posts is pretty clear what it does. It
GETs some posts.
You have a namespace:
wp, a version:
v2 and an object collection
Can you guess what:
GET wp-json/wp/v2/posts/5 does?
How about :
A developer can easily guess by looking at that, it's going to get the price of line
11 on order
345 even without reading the documentation. The dev can even easily tell that it's coming from the
shop Plugin as it is namespaced.
POST /wp-json/v2/posts title=New Blog Post
PUT /wp-json/v2/posts title=New Title
That's pretty clear as well. It makes a new post. By the way, it returns the ID of the new post. It's not about AJAX OR the REST API. AJAX is simply a technology that accesses the REST API. Whereas, before, you would have to come up with a bunch of abstract ajax function names like:
get_price_for_lineitem( $order, $line ). Is that going to return just a number, or a JSON object? I'm not sure, where's the documentation. Oh... was the ajax call
The developer doesn't have to make these decisions, because the existing
wp-json api provides a good base model to follow when creating your own endpoints. Sure, a plugin or api developer can break these rules, but in general it's easier to follow a standard that's already been set and most developers would much rather follow a pattern already set ( see how pervasive jQuery patterns are now ).
ABSTRACTION without distraction
Do I care about how
POST /wp-json/mysite/v1/widgets title=Foobar works? Nope. I just want to create a new
Widget and I want the ID in return. I wanna do it from a form on my front end without refreshing the page. If I make a request to a URL, I don't care if it's PHP,C#, ASP.NET or any other technology. I just want to create a new Widget.
The REST API decouples the backend from the front. Technically, if your API is good enough, you could change your entire backend stack. As long as you maintained the same REST API structure, anything that depended on the API would not be affected.
If your REST API is simple and consistent enough, using a noun like
Widgets as a collection of objects and noun/identifier like
Widget/2 to indicate a single entity, it's really straightforward to write that API in a vastly different technology as it's more or less basic database plumbing code.
Uses Standard HTTP Request verbs.
REST APIs leverage the core of how the web works and the VERBs ( read: action ) that you use map to standard data CRUD functions.
CREATE : POST
READ : GET
UPDATE : PUT/PATCH
DELETE : DELETE
There are more HTTP verbs, but those are the basics. Every single request over the internet uses these verbs. A REST API sits right on top of the model the web is built upon requests. No need for any communication layer or abstraction model in between. It's just a standard http request to a URL and it returns a response. You can not get much simpler than that.
Essentially, it makes a developer more aware of the nuts and bolts of how the web actually works and when you get closer to understanding how the underlying protocols work, you end up making a more efficient better product.