Infraestrutura CONSISTENTE
A API REST é consistente e legível por humanos. É auto-documentado.
GET wp-json/wp/v2/postsé bem claro o que faz. São GETalgumas postagens.
Você tem um espaço para nome:, wpuma versão: v2e uma coleção de objetosposts
Você consegue adivinhar o que: GET wp-json/wp/v2/posts/5faz? 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, olhando para isso, ele receberá o preço da linha 11, 345mesmo sem ler a documentação. O desenvolvedor pode facilmente dizer que é proveniente do shopplug-in, pois está no namespace.
Que tal POST /wp-json/v2/posts title=New Blog Post
Que talPUT /wp-json/v2/posts title=New Title
Isso é bem claro também. Faz um novo post. A propósito, ele retorna o ID da nova postagem. Não se trata de AJAX OU da API REST. AJAX é simplesmente uma tecnologia que acessa a API REST. Considerando que, antes, você teria que vir para cima com um monte de nomes de função ajax abstratos como:
get_price_for_lineitem( $order, $line ). Isso retornará apenas um número ou um objeto JSON? Não tenho certeza, onde está a documentação. Oh ... foi a chamada do ajax get_order_line_priceou get_lineitem_price.
O desenvolvedor não precisa tomar essas decisões, porque a wp-jsonAPI existente fornece um bom modelo básico a ser seguido ao criar seus próprios pontos de extremidade. Certamente, um desenvolvedor de plug-in ou API pode violar essas regras, mas, em geral, é mais fácil seguir um padrão já definido e a maioria dos desenvolvedores prefere seguir um padrão já definido (veja como os padrões difusos do jQuery são agora).
ABSTRACÇÃO sem distração
Eu me preocupo com como POST /wp-json/mysite/v1/widgets title=Foobarfunciona? Não. Eu só quero criar um novo Widgete quero o ID em troca. Quero fazê-lo a partir de um formulário no meu front end sem atualizar a página. Se eu fizer uma solicitação para um URL, não me importo se é PHP, C #, ASP.NET ou qualquer outra tecnologia. Eu só quero criar um novo widget.
A API REST desacopla o back-end da frente. Tecnicamente, se sua API for boa o suficiente, você poderá alterar toda a pilha de back-end. Enquanto você mantivesse a mesma estrutura da API REST, qualquer coisa que dependesse da API não seria afetada.
Se a sua API REST é simples e consistente o suficiente, usando um substantivo como Widgetsuma coleção de objetos e um substantivo / identificador Widget/2para indicar uma única entidade, é muito simples escrever essa API em uma tecnologia muito diferente, pois é um encanamento de banco de dados mais ou menos básico código.
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: ação) que você usa para mapear as 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 básicos. Cada solicitação pela Internet usa esses verbos. Uma API REST fica bem no topo do modelo em que a Web é criada mediante solicitações. Não há necessidade de qualquer camada de comunicação ou modelo de abstração no meio. É apenas uma solicitação HTTP padrão para um URL e retorna uma resposta. Você não pode ficar muito mais simples que isso.
Essencialmente, ele torna o desenvolvedor mais ciente dos detalhes de como a Web realmente funciona e, quando você se aproxima do entendimento de como os protocolos subjacentes funcionam, acaba criando um produto melhor, mais eficiente.