[Rio-pm] Cache RESTfulie

Renato Santos renato.cron em gmail.com
Segunda Março 11 22:06:19 PDT 2013


*Acho* que você deve criar uma função de entrada, cuja saida seja sempre a
mesma para determinados parametros, e ai você utiliza isso como chave.

vamos supor um REST assim:

   - POST /user
   - PUT /user/$id
   - DELETE /user/$id
   - GET /user
   - GET /user/$id

Você tem que apagar o cache corretamente quando alguem efetuar POST, PUT,
DELETE e fazer leituras (e escritas, caso não exista o cache) no cache no
GET.

Se for exatamente o REST acima, um mundo perfeito, é facil apagar o cache
das URL que são 'pais', por exemplo, editou o nome de um usuario, você tem
que apagar a listagem do usuario e o cache do get do usuario. Limpar toda a
lista dos usuarios pode se tornar um problema se você tem muitas escritas e
o o objeto em questão não estiver no /user (vamos supor que é paginado, ..)

e ai começam os problemas..


2013/3/12 Marcio Ferreira <marciodesouzaferreira em gmail.com>

> Desculpem, o título devia ser "cache RESTful"
>
>
> []s,
>
> Marcio Ferreira
> skype: marcio.ferreir4
> (21) 8365-7768
>
>
> 2013/3/12 Marcio Ferreira <marciodesouzaferreira em gmail.com>
>
>> (Imagina q nao existe varnish, nem nada no proxy, *OK*!)
>>
>> Tenho uma mesmo app service rodando em várias instancias balanceadas
>> pelo nginx.
>> Até aqui tudo bem, mas aí quero fazer cache dos acessos da API.
>>
>> penso.em/usar/minha/url como chave chave do Redis, alguém me condena por
>> isso?
>> Isso não parece ser uma boa prática, porque resolve até certo ponto, não
>> resolve se meu serviço aceita parametros via header =/
>>
>> Qual pratica recomendada/adotada quando vocês precisam cachear RESTfulie
>> a *nível de app*?
>>
>> []s,
>>
>> Marcio Ferreira
>> skype: marcio.ferreir4
>> (21) 8365-7768
>>
>
>
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>



-- 
Saravá,
Renato CRON
http://www.renatocron.com/blog/
@renato_cron <http://twitter.com/#!/renato_cron>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20130312/52da515d/attachment.html>


Mais detalhes sobre a lista de discussão Rio-pm