Design da API REST: diga ao servidor para "atualizar" um conjunto de recursos

Question

Temos alguns recursos em um servidor REST estruturado assim:

• /someResources/foo
• /someResources/bar
• /someResources/baz

Onde someResource é uma representação do servidor de um objeto distribuído distante.

Queremos dizer ao servidor para "atualizar" sua representação desse "objeto distribuído", olhando para ele na rede e atualizando o cache do servidor, ou seja, não podemos simplesmente colocar o novo valor.

Qual é o caminho de descanso limpo para isso?

a) é postar para um /refreshes/ Uma nova "solicitação de atualização"?

b) é para colocar (com um documento em branco) para http://ip/someResources ?

c) outra coisa?

Eu gosto (a), pois isso nos dará uma identificação para identificar e rastrear o comando Refresh, mas preocupado que estamos criando muitos recursos. Algum conselho?

Answer 1

Eu iria com a abordagem de recursos 'atualizações'. Isso tem dois grandes benefícios

(a) Como operações de ciclo de vida (cópia, clone, movimentação) O objetivo da atualização é ortogonal à função do recurso subjacente, portanto deve ser completamente separado

(b) Ele fornece uma maneira de verificar o progresso da atualização - o estado externo do recurso de atualização forneceria um atributo 'status' ou 'progresso'.

Implementamos as operações do ciclo de vida dessa maneira e a separação de preocupações é um grande design Plus.

Uma abordagem melhor

Outra maneira de gerenciar isso é permitir que o servidor cache sua representação do recurso por algum período de tempo, apenas verificando o estado real após algum tempo limite. Neste modelo, seu servidor é realmente um recurso intermediário de cache e deve seguir o comportamento de cache HTTP, consulte aqui para mais detalhes. Abaixo, cito uma seção muito relevante que fala sobre o cliente que substitui os valores em cache.

13.1.6 Comportamento controlado pelo clienteEmbora o servidor de origem (e, em menor grau, os caches intermediários, por sua contribuição para a idade de uma resposta) são a principal fonte de informações de vencimento, em alguns casos o cliente pode precisar controlar a decisão de um cache sobre se deve retornar um cache em cache resposta sem validá -lo. Os clientes fazem isso usando várias diretrizes do cabeçalho do controle de cache.

A solicitação de um cliente pode especificar a idade máxima que está disposta a aceitar uma resposta não validada; Especificar um valor de zero força o (s) cache (s) a revalidar todas as respostas. Um cliente também pode especificar o tempo mínimo restante antes que uma resposta expire. Ambas as opções aumentam as restrições ao comportamento dos caches e, portanto, não podem relaxar ainda mais a aproximação do cache de transparência semântica.

Um cliente também pode especificar que aceitará respostas obsoletas, até uma quantidade máxima de robustez. Isso afrouxa as restrições nos caches e, portanto, pode violar as restrições especificadas do servidor de origem na transparência semântica, mas pode ser necessário para apoiar a operação desconectada ou alta disponibilidade diante de baixa conectividade.

Chris

Answer 2

O cache HTTP parece permitir isso. http://www.w3.org/protocols/rfc2616/rfc2616-sec13.html#sec13.1.6

Defina o cabeçalho máximo = 0 e isso instruirá o servidor que o cliente deseja uma nova versão. Dessa forma, você pode continuar usando um Get.