finalidade da API REST?

15
Primeiro de tudo, eu entendo que este é um plugin no momento atual, mas certamente é quase parte do WordPress de qualquer maneira. Então, espero que isso não seja sinalizado como fora do assunto.

Eu li seus documentos oficiais, um monte de outros artigos e assisti vídeos tutoriais, mas eu ainda não estou recebendo alguns dos pontos .. Este é certamente o futuro do WordPress, é muito útil para o desenvolvimento de aplicativos móveis e usando / compartilhar dados entre sites diferentes, mas: o que isso faz apenas para o meu site?

Considere isto:

Estou atualmente trabalhando nos comentários. Quero que a seção de comentários seja carregada apenas quando o usuário rolar para a seção de comentários (com deslocamento de -200px, para que não haja atraso) .

  • Vou acionar a chamada do ajax quando o usuário rolar para esse ponto
  • Ajax envia alguns dados com ele, como post_id etc
  • Executar WP_Comment_Query() no servidor
  • Envie os dados JSON de volta para o cliente com relações de comentário, nomes, conteúdo etc
  • Use o JavaScript document.createElement() , innerHTML etc para criar e gerar comentários

Agora .. Por que eu usaria a API REST? Qual é a utilidade para mim? Apenas futuro?

Eu ainda precisaria usar JavaScript para produzir todos os dados que recebo .. Não encontrei nenhum bons artigos porque ou para o que eu deveria usar a API REST (exceto transferência de dados entre sites e desenvolvimento de aplicativos móveis) ..

    
por N00b 02.03.2016 / 18:50

7 respostas

6

No estado atual, é um recurso mal projetado que não tem nenhuma vantagem real para um desenvolvedor competente.

A ideia básica, como está no momento em que esta resposta é escrita, é expor a funcionalidade principal do WordPress como API REST JSON. Isso permitirá desacoplar a lógica de "negócios" do WordPress da interface do usuário e permitir a criação de diferentes UIs completas ou parciais para gerenciar e extrair informações do wordpress. Isso por si só não é uma revolução, mas uma evolução. apenas um substituto da API XML-RPC que por si só simplifica o HTTP para a API de envio.

Como em qualquer evolução, a cada passo você pode se perguntar, que vantagem você obtém do estado anterior, e a resposta provavelmente é "não muito", mas esperamos que os passos se acumulem para uma grande diferença.

Então, por que o prefácio negativo a essa resposta? Porque minha experiência como desenvolvedor de software é que raramente é possível projetar uma API genérica que seja realmente útil sem ter casos de uso concretos para responder. Um caso de uso concreto aqui pode substituir a API XML-RPC para gerenciamento automatizado de wordpress, mas qualquer front end relacionado deve ser específico do site e, como há uma grande penalidade de desempenho para cada solicitação enviada do cliente para o servidor, você não pode uso agregado de diferentes APIs para obter o resultado desejado de uma forma que os usuários permaneçam felizes. Isso significa que, para o front-end, para uso não trivial, ainda haverá pouca diferença no esforço de desenvolvimento entre o uso da rota AJAX e a rota REST-API.

    
por Mark Kaplun 03.03.2016 / 01:58
3

As duas vantagens principais são:

  1. Você pode (eventualmente) executar todas as tarefas administrativas sem a interface administrativa.
  2. Você pode obter todos os dados para exibição e eliminar o front end (e escrever PHP) completamente.

Em relação ao seu exemplo especificamente -

Substitua as etapas 3 e amp; 4 com a API REST e substitua as etapas 1, 2 e 5 pelo Backbone.js. BOOM, aplicação web dinâmica. Ou talvez você esteja mais confortável fazendo o roteamento complexo necessário para o seu site com o Python.

    
por Milo 02.03.2016 / 19:55
3

Bem, algumas coisas na verdade.

  1. Ele permite que você execute funções específicas conforme necessário, em vez de exigir todo o processamento de um carregamento de página inteiro. Assim, você pode atualizar os comentários periodicamente com pouca sobrecarga sem precisar de uma atualização de página apenas chamando esse ponto de extremidade da API e atualizando os dados em sua página. Esse conceito acabará sendo extrapolado para SPAs (aplicativos de página única) que carregam o site "cliente" rapidamente uma vez e emula todas as "alterações" de página sem precisar retroceder o HTML da página a cada vez. Isso já é muito popular com o advento de estruturas como Angular, Ember e React. Os sites podem responder com uma velocidade impressionante, enquanto ambos descarregam algum poder computacional para o usuário final (ciclo de renderização, lógica não comercial) e reduzem significativamente o número geral de chamadas ao servidor (apenas extrai os dados de que você precisa, em vez de recarregar tudo a cada vez).

  2. Ele separa a lógica de negócios e o renderizador. Sim, você pode usar a API com outro site PHP cuspindo os resultados, ou manipulá-lo com Javascript como mencionado, mas você também pode consumi-lo com um aplicativo móvel nativo, aplicativo de desktop, etc. Não apenas isso, mas você poderia ter um de cada um falando com a mesma API, que realiza consistentemente a mesma lógica de negócios, o que, por sua vez, cria consistência e confiabilidade entre os vários clientes que consomem a API.

As APIs são boas porque separam as preocupações da lógica e da exibição.

    
por Colt McCormack 02.03.2016 / 22:05
2

A API REST do WordPress é o novo hotness. Com aplicativos voltados para uma única página, e o WordPress deseja se tornar uma plataforma de aplicativos, isso faz muito sentido. O plano é substituir o XML-RPC pela API REST (o que é bom por razões de segurança!)

enlace

  • O site novo de Nova York é construído sobre ele, aparentemente .
  • Permite que aplicativos móveis e outros serviços externos acessem conteúdo wp (como wp-cli )
  • Permite que os desenvolvedores criem um front-end de aplicativo de página única com seus estrutura de consumo JSON favorita da semana e ter todos os interações legais na ponta dos dedos.
  • Permite a separação de interesses (como mencionado acima) e maior independência entre as equipes de back-end e front-end.

É outro conjunto de ferramentas para levar o WordPress adiante. E, embora tenha sido uma jornada sinuosa para chegar onde estamos, acho que vale a pena dedicar um tempo para explorá-lo e compreendê-lo.

    
por Jeremy Ross 02.09.2016 / 20:27
1

Primeiras coisas primeiro - REST é leve

Em uma linha - Quando usamos APIs REST, fazemos toda a renderização de dados no lado do cliente (loops, condições e chamadas do servidor, etc.) economizando largura de banda e ao mesmo tempo nosso aplicativo se torna pronto para qualquer plataforma móvel, integrações de terceiros e modularizadas frontend e server side).

Você não quer isso?

    
por Divyanshu Jimmy 12.08.2017 / 07:31
0

Além dos dois ótimos pontos mencionados no @Milo, uso especificamente a API REST para expor meus dados a aplicativos que não são WordPress. Temos uma extensão do Chrome que extrai informações do nosso banco de dados do WordPress, e isso é feito atingindo os endpoints da API REST com solicitações POST.

    
por Nick F 02.03.2016 / 21:00
0

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.

    
por Armstrongest 07.12.2017 / 02:37

Tags