Infraestrutura consistente
A API REST é consistente e legível por humanos. É auto-documentado.
GET wp-json/wp/v2/posts é bastante claro o que faz. É GET s algumas postagens.
Você tem um namespace: wp , uma versão: v2 e uma coleção de objetos posts
Você consegue adivinhar o que: GET wp-json/wp/v2/posts/5 faz?
Que tal: GET wp-json/wp/v2/posts/5/comments
Que tal: GET wp-json/shop/v2/orders/345/lines/11/price
Um desenvolvedor pode adivinhar facilmente que, olhando para isso, ele obterá o preço da linha 11 no pedido 345 , mesmo sem ler a documentação. O desenvolvedor pode até mesmo dizer facilmente que está vindo do shop Plugin, já que ele é namespaced.
Que tal POST /wp-json/v2/posts title=New Blog Post
Que tal PUT /wp-json/v2/posts title=New Title
Isso é bem claro também. Faz um novo post. By the way, ele retorna o ID do novo post. Não é sobre o AJAX ou a API REST. O AJAX é simplesmente uma tecnologia que acessa a API REST. Considerando que, antes, você teria que criar um monte de nomes abstratos de funções do ajax como:
%código%. Isso vai retornar apenas um número ou um objeto JSON? Não tenho certeza, onde está a documentação. Ah ... foi a chamada do ajax get_price_for_lineitem( $order, $line ) ou get_order_line_price .
O desenvolvedor não precisa tomar essas decisões, porque o get_lineitem_price api existente fornece um bom modelo base a seguir ao criar seus próprios pontos de extremidade. Claro, um desenvolvedor de plugin ou api pode quebrar essas regras, mas em geral é mais fácil seguir um padrão que já foi definido e a maioria dos desenvolvedores prefere seguir um padrão já definido (veja como padrões de jQuery são agora).
ABSTRAÇÃO sem distração
Eu me importo com a forma como o wp-json funciona? Não. Eu só quero criar um novo POST /wp-json/mysite/v1/widgets title=Foobar e eu quero o ID em troca. Eu quero fazer isso de um formulário no meu front end sem atualizar a página. Se eu fizer uma solicitação para uma URL, não me importo se for PHP, C #, ASP.NET ou qualquer outra tecnologia. Eu só quero criar um novo Widget.
A API REST separa o back-end da frente. Tecnicamente, se sua API é boa o suficiente, você pode alterar toda a sua pilha de back-end. Contanto que você mantivesse a mesma estrutura da API REST, tudo o que dependesse da API não seria afetado.
Se a sua API REST for simples e consistente o suficiente, usando um substantivo como Widget como uma coleção de objetos e substantivo / identificador como Widgets para indicar uma única entidade, é realmente simples escrever essa API em uma variedade muito diferente tecnologia como é mais ou menos básico código de banco de dados de encanamento.
Usa verbos de solicitação HTTP padrão.
As APIs REST aproveitam o núcleo de como a Web funciona e os VERBs (leia-se: action) que você usa mapeiam para funções CRUD de dados padrão.
CREATE : POST
READ : GET
UPDATE : PUT/PATCH
DELETE : DELETE
Existem mais verbos HTTP, mas esses são os princípios básicos. Cada solicitação única pela internet usa esses verbos. Uma API REST fica bem em cima do modelo em que a web é construída sobre as solicitações. Não há necessidade de nenhuma camada de comunicação ou modelo de abstração no meio. É apenas uma solicitação HTTP padrão para uma URL e retorna uma resposta. Você não pode ficar muito mais simples que isso.
Essencialmente, isso torna um desenvolvedor mais consciente das porcas e parafusos de como a web realmente funciona e quando você está mais perto de entender como os protocolos subjacentes funcionam, você acaba criando um produto melhor e mais eficiente.