Endpoints da API especializados ou várias chamadas para recursos genéricos?

Question

Endpoints da API especializados ou várias chamadas para recursos genéricos?

#1 resposta do (4 votos)

5

Esse problema surgiu ao projetar a API para um aplicativo da web do SPA, que se comunica com o servidor via AJAX.

Em uma página, o usuário, que está criando uma lista de pessoas para convidar para um evento, tem a opção de adicionar pessoas que foram convidadas para eventos anteriores. Imagine uma lista suspensa contendo os nomes dos eventos anteriores. Quando um evento é selecionado, um multiseleto é preenchido com todos os convidados para o evento anterior. O usuário pode selecionar essas pessoas e pressionar "Adicionar", que as adiciona à lista de convidados do evento atual.

Se você imaginar a estrutura de dados por trás do menu suspenso / multiseleto descrito, pode ser algo como isto:

previousEventGuests [
  { 
    eventName: 'Company Christmas Dinner',
    guests: ['Joe Smith', 'Andy Jones', ...]
  },  
  ...
]

Surge a pergunta: como essas informações são baixadas da API?

Eu vejo duas abordagens de alto nível:

Escreva um ponto de extremidade da API específico para atender a essa necessidade específica:
```
/previousEventsAttendees
```

que retorna exatamente os dados acima.

Faça várias chamadas para endpoints de recursos genéricos

/events                    (foreach event_id returned, call....)
  /event/:event_id         (to get each event's name)
  /event/:event_id/guests  (forach list of user_ids returned, call...)
    /user/:id              (to actually get each users name)

Os profissionais de 1. são que você só precisa fazer uma única chamada AJAX e tem muito menos código de processamento de dados no cliente. O principal problema que vejo é que você construiu um endpoint strongmente acoplado a essa visão específica dentro desse aplicativo em particular.

Os prós de 2. são que estamos usando nada além de endpoints de recursos genéricos, que poderiam ser reutilizados por muitos modos de exibição e aplicativos diferentes. Os contras são que temos que fazer muitas chamadas AJAX e juntar todas as respostas para obter o formato que queremos.

Minhas perguntas são: 1. Que fatores devo considerar ao tomar esse tipo de decisão? O fato de essa API ser uma API interna da empresa (e quase certo que permaneça assim), em vez de pública, pode influenciar minha decisão? Existe uma maneira de obter o melhor dos dois mundos? 2. Eu sei que este é um problema geral ligado aos princípios do REST, e com muitas soluções (eu acredito que o Falcor é uma abordagem mais nova para resolver pelo menos um problema similar). Eu deveria estar olhando para outras abordagens?

design api-design api rest

por Jonah 30.06.2016 / 02:26

fonte

1 resposta

Tags design api-design api rest

Como lidar com operações de matriz grande em Javascript? Padrão de especificação e princípio fechado aberto

score 4 · Accepted Answer

Por que não os dois?

O que significa, sim, que há trade-offs a considerar, mas se o custo marginal de implementar uma segunda opção for pequeno, você pode oferecer aos seus clientes a capacidade de selecionar qual representação eles preferem, para que eles possam escolher seus próprios trade-offs (claro, há alguma penalidade de complexidade a ser paga oferecendo uma escolha, em vez de resolver o "problema" para os clientes).

The major con I see is that you've built an endpoint tightly coupled to this particular view within this particular application.

Não é exatamente a linguagem certa, do ponto de vista do REST. Não é o endpoint que é acoplado ao aplicativo, mas o tipo de mídia da representação.

Naturalmente, preocupar-se com tipos de mídia tende a ficar de lado quando estamos implementando o cliente e o servidor, e seus ciclos de lançamento são acoplados.

The pros of 2. are that we are using nothing but generic resource endpoints, which could be re-used by many different views and applications.

Esse pensamento está incompleto - você pode não apenas reutilizar os endpoints, mas pode reutilizar as próprias representações ... ex: cache. Se o cliente puder extrair os dados que ele precisa de seu próprio cache, não será necessário fazer uma viagem de ida e volta. Caso contrário, um cache intermediário já pode ter uma cópia dos dados, encurtando a viagem de ida e volta. O "servidor" com o qual o cliente está falando pode ser um farm de cache na frente do seu aplicativo, mantendo a carga de trabalho baixa e, ao mesmo tempo, podendo ser expandida.

No REST, você quer ter certeza de que seus projetos aproveitam a interface uniforme.

Então, uma das coisas em que você deve pensar é o tempo de vida de cache de seus recursos; Por quanto tempo as representações são válidas? Outras visualizações e aplicativos poderão tirar proveito disso?

Should the fact that this API is an internal company API (and almost certain to remain so), rather than a public facing one, influence my decision?

Isso provavelmente limitará o volume de tráfego necessário para o suporte. Além disso, se todos os clientes tiverem uma localização central, o tempo de ida e volta também cai como uma preocupação.