Apresentação na QCon SP /ou: Ai vai o PPT

Primeiro, obrigado pelo pessoal que apareceu lá e principalmente para os que questionaram e/ou compartilharam um pouco dos problemas e soluções com a gente! Foi realmente muito bacana! A idéia era essa: compartilhar experiências. Objetivo mais do que alcançado!

Antes que esfrie, ai vai a apresentação:

Case CMS Abril - System of Systems e Arquitetura (quase) Caótica.

Apresentação na QCon SP

Primeiro queria agradecer ao pessoal que compareceu no DevInSampa (fotos)! Foi muito bacana, com o pessoal fazendo perguntas bem interessantes.

Agora esperamos você na QCon SP!

Case CMS Abril - System of Systems e Arquitetura (quase) Caótica.
Ao aceitar que organizações são sistemas amplos, orgânicos e complexos, devemos adaptar nossa arquitetura a esta realizade. Como viabilizar um enterprise system que se adapte com a velocidade necessária as mudanças de requisitos, conflitos de necessidades dentro deste paradigma?
Para tanto, será explorada a teoria de Sistemas Complexos Adaptáveis e Emergência x BDUF, System of Systems e REST Archtectural Style e como estes conceitos estão ajudando a Abril a construir o parque de aplicações que suporta a publicação de mais de 100 sites e provê mais de 300 milhões de requests/mês.

Apresentação no Dev in Sampa

A apresentação no Dev in Sampa foi aprovada. Obrigado pelos votos! Espero você lá!

Apresentação no Dev in Sampa

Estamos concorrendo com uma apresentação no Dev in Sampa, que acontece no dia 14/08. Vota lá! :)

REST in Sampa: Case CMS Abril
Ao aceitar que organizações são sistemas amplos, orgânicos e complexos, devemos adaptar nossa arquitetura a esta realizade.
Como viabilizar um enterprise system que se adapte com a velocidade necessária as mudanças de requisitos, conflitos de necessidades dentro deste paradigma?
Para tanto, será explorada a teoria de Sistemas Complexos Adaptáveis e Emergência x BDUF, System of Systems e REST Archtectural Style e como estes conceitos estão ajudando a Abril a construir o parque de aplicações que suporta a publicação de mais de 100 sites e provê mais de 300 milhões de requests/mês.

Link Relations /ou: What the rel?

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.