REST e URI Cache

Question

Pelo que entendi, usando um hipertexto-driven serviço RESTful web, um cliente não é suposto saber nada sobre servidor esquema URI, exceto por um par de pontos de entrada bem conhecidos. Isto é suposto para permitir que o servidor para controlar o seu próprio espaço URI e reduzir o acoplamento com o cliente.

Quando um cliente para o serviço envia uma solicitação bem-sucedida para criar um novo recurso, o serviço responde 201 criada e dá a URI em que o novo recurso pode ser acessado no campo Location cabeçalho.

Se um cliente ter permissão para armazenar esse URI para permitir acesso direto ao recurso no futuro e em caso afirmativo por quanto tempo? Se URIs são armazenados em cache pelo cliente, esta parece ser a criação de uma situação em que cada vez que o servidor muda seu layout URI, ele vai precisar para se certificar de um redirecionamento permanente fica servido quando URIs velhos são acessados. Caso contrário, as quebras de cliente. Ao longo de vários anos, este sistema de redirecionamentos poderia sair da mão.

Esta situação não parece ter dado o servidor muito mais controle sobre seu espaço de URI do que uma abordagem híbrida RESTO-RPC usando modelos URI.

Há uma grande quantidade de informação disponível sobre as representações de Cache, mas que sobre o cache de URIs em sistemas RESTful-driven hipertexto?

Answer 1

Lembre-se, como disse Tim Berners-Lee, "esfriar URLs não mudam". Depois que o servidor distribui um URI para o cliente, agora é o trabalho do servidor para manter o funcionamento URI no futuro, (por exemplo) o envio de uma resposta Movido-permanentemente no caso do URI mudou e alguém solicita o antigo.

Este é realmente o que incentiva muitos a projetar URIs opacos, como base em ids banco de dados ou data e hora, em vez de usar alguma propriedade legível do recurso na URI. Qualquer coisa que as pessoas entendam, eles vão querer mudança.

Answer 2

Sim, o cliente deve ter a possibilidade de armazenar o URI. Para contanto que ele quer. Como Licky mencionou um cliente inteligente pode usar uma resposta Movido-permanentemente para atualizar seus marcadores.

Se você pensar sobre isso, temos a melhor situação possível. Você pode alterar as urls no servidor, enquanto escolhendo ainda apoiar os clientes antigos para contanto que nós escolhemos, e os clientes inteligentes pode efetivamente auto update-se às novas urls.

Quanto tempo você optar por continuar a apoiar essas URLs antigos é realmente uma decisão que precisa ser feita com base nos clientes existentes e a facilidade com que eles podem ser mantidos.

Para mim esta é uma grande melhoria sobre as questões de controle de versão com interfaces de estilo RPC.

Answer 3

Eu sei que isto é uma questão de idade, mas eu acho que há um subcomponente para as respostas que eu vejo aqui que não tenha sido abordada.

Lembre-se que você não está recuperando o recurso do servidor, mas você está recuperando uma representação de um recurso. O recurso em si pode ter sua mudança identificador primário, ou ser realojadas, ou o que quer, mas a representação que foi devolvido ao cliente na criação de recurso pode (ou não ser) válido independentemente; é tudo uma questão de situação.

Como um exemplo, considere um sistema de carregamento de conteúdo moderado; um usuário pode ter a capacidade de fazer upload de conteúdo para consideração pelos moderadores que podem eventualmente causar o conteúdo a ser expostos a um público / mercado mais amplo. No carregamento inicial, o servidor pode responder com um URI que direciona para (digamos) "users / {ID de usuário} / uploaded / {contentid}" para que a representação desse conteúdo. Em algum momento, os moderadores pode decidir promover o conteúdo para uma "página inicial"; que a representação do conteúdo pode ser então disponível no URI do "teor / {contentid}"; que não deve impedir o uploader originais de acessar seus dados em "usuários / {ID de usuário} / uploaded / {contentid}"; nada diz que é preciso haver um redirecionamento permanente, e de fato, há uma boa razão para não haver; se o usuário decide que quer remover o conteúdo, eles devem ser capazes de executar um DELETE no conteúdo; é provavelmente muito preferencial para que os usuários fazendo DELETEs para as representações de conteúdo de seu próprio "enviados" locais. No entanto, se os termos do site indicam que os direitos de utilização de conteúdo carregado são revogados (não é incomum) pode fazer sentido ter o processo de promoção moderação efetivamente remover o conteúdo da própria área do usuário, causando uma "mudança permanente".

É realmente inteiramente dependente da situação específica; a validade de um URI em cache é completamente dependente de políticas do servidor. Pelo menos, eu acho que uma solicitação para um URI inválido (que podem ter sido previamente válido) deve causar uma resposta (consistente com HATEOAS) que pode permitir que o cliente "redescobrir" o recurso (representação) que eles estavam procurando ; no mínimo, um link para o ponto de entrada.

Answer 4

Uma vez que um dos princípios do REST é que os recursos são endereçáveis, parece perfeitamente aceitável para um cliente para acompanhar o endereço (URI) para um determinado recurso. Resource URIs deve ser um dos "pontos de entrada bem conhecidos" que você referidos.