Estamos utilizando representações hipermídia (HATEOAS) a algum tempo já. Uma discussão que fica interessante é quando alguém pergunta: O que eu coloco no rel do link?
Aqui vai o que pensamos sobre o assunto e como estamos utilizando aqui na Abril.
No geral, o rel indica qual a relação do link com o atual recurso. O rel="prev" do Atom, por exemplo, indica que o link vai para a página anterior em relação a página atual. Logo a semântica que o rel de um link carrega depende do recurso atual (página atual), do media type (Atom) e do contexto. Veremos...
1. O recurso atual
Todo rel deve dar um significado ao link em relação ao recurso atual:
- Mudar o estado do próprio recurso: (um PUT para o rel="self", por exemplo)
- Recursos relacionados: rel="comentarios", rel="materias_associadas"
- Navegar para a próxima parte de um fluxo: rel="next"
2. Media type
Alguns media types fixaram em suas especificações os valores que o rel pode receber. Para citar alguns, o Atom tem os seus assim como o HTML.
Problema? Imagine um recurso representado em Atom, com o link rel="related". Este link deve indicar "recursos relacionados" nessa representação. Mas e caso estivéssemos usando um outro media type que também tivesse uma predefinição para rel="related", mas com outro significado? Lembre-se que um recurso pode ser representado em vários media types e os links com rel que indicam qual a navegação do fluxo.
Ainda no caso Atom, caso você queira usar algum outro rel que não esteja na lista, é necessário usar uma URI. Algo como rel="http://blabla.com/proxima_semana". A idéia é que a URI leve a documentação da relação.
3. Contexto
O contexto no qual a representação vai ser usada é relevante. Vejo 3 contextos:
- Machine-2-Machine na Web: o recurso e suas representações estão visíveis na web.
- Machine-2-Machine em um ambiente fechado (enterprise integration): o recurso e suas representações estão visíveis apenas em um ambiente onde os clients são conhecidos.
- Human-2-Machine: o recurso e suas representações são lidos por uma pessoa. No caso da web, esta página HTML que você está lendo serve de exemplo. Mas poderíamos pensar na Web API do twitter e um desenvolvedor lendo o recurso raw da API, tentando criar uma automação.
Respondendo a pergunta: O que eu coloco no rel do link?
O rel deve expressar o mais claro possível a relação do recurso atual com o link. De preferência um subjetivo e não um verbo.
O recurso vai ficar exposto na web? Se sim, tente respeitar as especificações do media type para rel conhecido ("prev", "next", por exemplo), mesmo correndo o risco de conflito entre media types. Crawlers podem navegar pelo seu conteúdo e gerar relacionamento entre eles já que o rel é conhecido. No entanto, micro formatos fariam um trabalho melhor aqui. E para rel não conhecido, não utilizar URIs. Além de complicar o código do client, a URI no rel dificulta a leitura do nosso amigo desenvolvedor externo, além de não mudar a atitude dos crawlers.
Caso o recurso não esteja exposto na web, ignore completamente as especificações do media type e de preferência a rel com nomes claros que seus clients consigam entender facilmente (linguagem ubíqua).
Conclusão
A verdade é que a discussão sobre linked data ainda está aberta nos comitês do W3C.
Enquanto não existe um padrão claro, nossa visão tenta ser pragmática, baseada em cenários conhecidos por nós e baseado também em outros casos de serviços na web.
0 comentários:
Postar um comentário