Este documento discute a arquitetura RESTful implementada no sistema Alexandria da Abril Mídia. Resume as seguintes informações essenciais: 1) O sistema é composto por vários domínios, serviços e sites que se comunicam através de uma arquitetura orientada a recursos e protocolo HTTP. 2) A arquitetura RESTful foi escolhida por permitir escalabilidade, desempenho, disponibilidade e evolução independente dos componentes. 3) Os principais desafios enfrentados foram a diversidade de requisitos e a

1. Como um grande
sistema REST funciona

2. David Robert
davidrobert@gmail.com
twitter: while42
github: davidrobert

4. AMBIENTE

6. gráfica
distribuidora
educação

7. Playboy Veja
Quatro Rodas
Super Interessante
Placar

8. “organizações que projetam sistemas são
restritas a produzir projetos que são cópias
das estruturas de comunicação dessas
organizações”
Lei de Conway
http://www.melconway.com/Home/Conways_Law.html

9. CMS’s existem desde os anos 90.
Por que reiventamos a roda?

10. Porque temos
alta diversidade
de
requisitos
negócios
pessoas
orçamentos
prioridades
culturas
{

11. boa
arquitetura
necessidades
atendidas
custo
aceitável
= + *ß
ßquão bem o seu cliente
sabe pedir o que quer :-P
MTRH
MTRH
mean time to
recovery happiness

13. diretoria digital
Playboy
Veja
Quatro Rodas

14. RAIO X

15. 16 sites em produção

16. +/- 60 desenvolvedores
13 arquitetos de software
6 Gerentes de Projeto
4 Gerentes de Produto
1 Advocate da Plataforma

17. • MongoDB
• MySQL
• Hbase
• HDFS
• PostgreSQL
• memcached
• redis
• ruby
• java
• javascript
• rails
• sinatra
• goliath
• node.js
• play
• jetty
• tokamak
• cachebag
• HTTPMonkey
linguagens storage frameworks outros
• Solr
• Hadoop
• RabbitMQ
• Varnish
• New Relic
https://github.com/abril

18. infraestrutura Alexandria + sites
• 91 VMs para ambientes dev, qa, stage
• AMC (Abril Mídia Cloud): private cloud (Xen/Open Stack)
• ou VMWare
• ~100 VMs + 20 físicas para produção
• Data center próprio, AWS, Heroku
• Total aproximado: 220 máquinas

19. +15 milhões de pageviews
(de jan até fev de 2013)

20. HTTP

21. domínio
• acesso e manipulação de recursos
• implementa regras de negócio
• servidor HTTP + base de dados
• infra “isolada”
• ~ 8 domínios
• ex: editorial (matérias, galerias, etc), anotações
(comentários), estabelecimentos, mídia, pessoas

22. serviço
• consumo e manipulação de recursos
• servidor HTTP + (opcional base de dados)
• infra “isolada”
• ~ 12 serviços
• ex: console, socialcore, search, Abril ID, abr.io, etc

23. data-entry
• entrada da Redação
• aplicação web
• ~ 1 para cada domínio
• “API explorer”

25. sitetools• admin do site
• manipulação das áreas e templates
• agiliza criação de produtos
• a fronteira com o usuário
• opcional

27. HTTP
domínio
serviço
data-entry sitetools

28. system of systems

29. REST

30. Por que escolhemos REST?
• Protocolo de transferência amplamente
utilizado
• Escalabilidade
• Performance alta
• Alta disponibilidade
• Permitir evolução sem parar o sistema
• Permitir evolução sem quebrar os clientes
• Segurança

31. Por que escolhemos REST?
• HTTP
• Escalabilidade
• Performance alta
• Alta disponibilidade
• Permitir evolução sem parar o sistema
• Permitir evolução sem quebrar os clientes
• Segurança

32. Por que escolhemos REST?
• HTTP
• Web Caches
• Performance alta
• Alta disponibilidade
• Permitir evolução sem parar o sistema
• Permitir evolução sem quebrar os clientes
• Segurança

33. Por que escolhemos REST?
• HTTP
• Web Caches
• Web Proxies (localização geografica)
• Alta disponibilidade
• Permitir evolução sem parar o sistema
• Permitir evolução sem quebrar os clientes
• Segurança

34. Por que escolhemos REST?
• HTTP
• Web Caches
• Web Proxies (localização geografica)
• Load Balancers “comoditizados”
• Permitir evolução sem parar o sistema
• Permitir evolução sem quebrar os clientes
• Segurança

35. Por que escolhemos REST?
• HTTP
• Web Caches
• Web Proxies (localização geografica)
• Load Balancers “comoditizados”
• Load Balancers
• Permitir evolução sem quebrar os clientes
• Segurança

36. Por que escolhemos REST?
• HTTP
• Web Caches
• Web Proxies (localização geografica)
• Load Balancers “comoditizados”
• Load Balancers
• HTML, JSON, XML
• Segurança

37. Por que escolhemos REST?
• HTTP
• Web Caches
• Web Proxies (localização geografica)
• Load Balancers “comoditizados”
• Load Balancers
• HTML, JSON, XML
• HTTPS / TLS

38. REST= +LCODC$SS
Porque...
U
o_O

39. REST= +LCODC$SS
Porque...
U
Layered-Code on Demand-Client-Cache-Stateless-Server

40. REST= +LCODC$SS U
Client-Server
• Separação de responsabilidades
• Escalabilidade (simplificação)
• Evolução independente
http://byterot.blogspot.co.uk/2012/06/what-i-think-coupling-is.html

41. REST= +LCODC$SS U
Client-Server no Alexandria
• Separação de responsabilidades
• entre domínios e sites
• entre domínios e data entries
• entre domínios e serviços
• Escalabilidade
• funcionalidade implementada nos clients
• domínios só lidam com recursos (simplicidade)
• Evolução independente
• em certos pontos da arquitetura não há
• falta retro-compatibilidade

42. REST= +LCODC$SS U
• Visibilidade
• Escalabilidade
(recursos alocados)
• Confiabilidade
• Performance de rede
Stateless

43. Stateless no Alexandria
• HATEOAS implementado nas APIs
• cookies nas operações destrutivas
REST= +LCODC$SS U

44. REST= +LCODC$SS U
• Eficiência
• Escalabilidade
• Performance
percebida pelo usuário
• Confiabilidade
Cache

45. Cache no Alexandria
• Built-in no protocolo HTTP
• shared-caches instanciados entre alguns nós
• pesquisa sobre caches locais
• nem todos os nós implementam estratégia de cache
• purge de recursos diretamente no cache
REST= +ULCODC$SS

46. REST= +LCODC$SS U
• Encapsula complexidade
• Evolvabilidade
• Simplicidade
• Performance percebida
pelo usuário
Layered System

47. • shared-caches
• gateways para expor API para a Web
• balanceadores de carga
• encapsulamento de autenticação corporativa
• encapsulamento de legado
• permite evolução incremental do legado
REST= +ULCODC$SS
Layered System no Alexandria

48. REST= +LCODC$SS U
• Extensibilidade
• Simplificação do client
• Visibilidade
Code-on-demand

49. • widgets dos data-entries
• no futuro, o console também será instanciado assim
• é um elemento importante do REST que foi esquecido
por um tempo pela nossa arquitetura
REST= +ULCODC$SS
Code-on-demand no Alexandria

50. REST= +LCODC$SS U
• Simplificação pela generalidade
• Visibilidade
• Desacoplamento
• Evolvabilidade
• Performance percebida
pelo usuário
• Restrita a dados com
granularidade larga
Uniform interface

51. REST=
niform interface no Alexandria
+LCODC$SS
U

52. Uresource identification
URIuniversal resource identifier

53. Uresource identification
/:tipo_recurso/:id

54. Uresource identification
http://editorial.api.abril.com.br/materia/dicas
http://editorial.api.abril.com.br/materia/ac23657fg
http://bebe.abril.com.br/materia/ac23657fg

55. Uresources

56. Uresources
{
"tipo_recurso" : "materia",
"link" : [
{
"href" :
"http://editorial.api.abril.com.br/materia/4f0dea5a1e13694",
"rel" : "self",
"type" : "application/json"
},
{
"href" : "http://editorial.api.abril.com.br/materias",
"rel" : "materias",
"type" : "application/json"
}
],
"id" : "http://editorial.api.abril.com.br/materia/4f0dea5a1e13694",
"slug" : "o-quintal-da-realeza",
"marca" : "viajeaqui",
"status" : "disponivel",
"descricao_conteudo" : "O quintal da realeza",
"fonte" : "viajeaqui",
(continua)

57. Urepresentations
JSON

58. Urepresentations
e um tiquinho assim de XML
ou melhor,
de application/opensearchdescription+xml

59. Urepresentations
<?xml version="1.0" encoding="UTF-8"?>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/"
xmlns:grafo="http://socialcore.api.abril.com.br/grafo/busca">
<ShortName>Buscar relacionamentos</ShortName>
<Description>Busca de relacionamentos no grafo</Description>
<Url type="application/json"
template="http://socialcore.api.abril.com.br/grafo/busca?
usuario={grafo:usuario?}&amp;tipo={grafo:tipo}"/>
<Query role="example"
title="Exemplo de valores dos parâmetros"
grafo:usuario="id do usuario"
grafo:tipo="segue |seguido_por " />
</OpenSearchDescription>

60. Uhypermedia
Exercício: criar uma atividade de
um usuário no site.
Você só sabe o entrypoint:
http://socialcore.api.abril.com.br

61. Uhypermedia
POST http://socialcore.api.abril.com.br/
Accept: application/json

62. Uhypermedia
POST???

63. Uhypermedia
HTTP/1.1 405 Method Not Allowed
Allow: GET

64. Uhypermedia
GET http://socialcore.api.abril.com.br/
Accept: application/json

65. Uhypermedia
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
{
"titulo": "socialcore",
"link": [
{
"href": "http://socialcore.api.abril.com.br/",
"rel": "self",
"type": "application/json"
},
{
"href": "http://socialcore.api.abril.com.br/atividade",
"rel": "atividade",
"type": "application/json"
},
{
"href": "http://socialcore.api.abril.com.br/grafo",
"rel": "grafo",
"type": "application/json"
}
]
}

66. Uhypermedia
GET http://socialcore.api.abril.com.br/atividade
Accept: application/json

67. Uhypermedia
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
{
"titulo": "Entry Point de Atividades",
"link": [
{
"href": "http://socialcore.api.abril.com.br/atividade/template",
"rel": "template",
"type": "application/json"
},
{
"href":
"http://socialcore.api.abril.com.br/atividade/busca/descritor",
"rel": "search",
"type": "application/opensearchdescription+xml"
},
{
"href":
"http://socialcore.api.abril.com.br/atividade/stat/descritor",
"rel": "stat",
"type": "application/opensearchdescription+xml"
}
]
}

68. Uhypermedia
GET http://socialcore.api.abril.com.br/atividade/template
Accept: application/json

69. Uhypermedia
HTTP/1.1 200 OK
Content-Type: application/json;
charset=utf-8
{
"atividade": {
"app": "",
"created_at": "",
"usuario": "",
"tipo": "",
"objeto": {
"tipo": ""
},
"resultado": {
"tipo": ""
}
},(continua)

70. Uhypermedia
"link": [
{
"href": "http://socialcore.api.abril.com.br/atividade",
"rel": "atividade",
"type": "application/json"
},
{
"href":
"http://socialcore.api.abril.com.br/atividade/busca/descritor",
"rel": "search",
"type": "application/opensearchdescription+xml"
},
{
"href":
"http://socialcore.api.abril.com.br/atividade/stat/descritor",
"rel": "stat",
"type": "application/opensearchdescription+xml"
}
]
}

71. Uhypermedia
POST http://socialcore.api.abril.com.br/atividade
Accept: application/json
Content-Type: application/json; charset=utf-8
Authentication: Basic 37rnx9w87rjdw87gri
{
"atividade": {
"app": "http://aapg.api.abril.com.br/produtos/1",
"created_at": 1325086429,
"tipo": "comentar",
"objeto": {
"descricao": "Titulo da materia",
"id":
"http://veja.abril.com.br/noticia/economia/confianca-da",
"tipo": "materia"
},
"resultado": {
"corpo": "otima materia",
"id":
"http://veja.abril.com.br/noticia/economia/confianca-da/comments/1",
"tipo": "comentario"
}

72. Uhypermedia
HTTP/1.1 422 Unprocessable Entity
Content-Type: application/json; charset=utf-8
{
"tipo_recurso":"erro",
"atividade":{
"usuario":"",
},
"erros":[
{"atributo":"usuario","mensagem":["é obrigatório"]}
]
}

73. Uhypermedia
POST http://socialcore.api.abril.com.br/atividade
Accept: application/json
Content-Type: application/json; charset=utf-8
Authentication: Basic 37rnx9w87rjdw87gri
{
"atividade": {
"app": "http://aapg.api.abril.com.br/produtos/1",
"created_at": 1325086429,
"usuario": "http://aapg.api.abril.com.br/usuarios/2",
"tipo": "comentar",
"objeto": {
"descricao": "Titulo da materia",
"id":
"http://veja.abril.com.br/noticia/economia/confianca-da",
"tipo": "materia"
},
"resultado": {
"corpo": "otima materia",
"id":
"http://veja.abril.com.br/noticia/economia/confianca-da/comments/1",
"tipo": "comentario"

74. Uhypermedia
HTTP/1.1 201 Created
Content-Type: application/json; charset=utf-8
Location: http://socialcore.api.abril.com.br/atividade/0922307
o/

75. Uapplication protocol
HTTPstatus codes
representation metadata
resource metadata
control data

76. Lições aprendidas

77. pontos importantes em performance
client
origin server
• performance dos
connectors
• non-blocking
HTTP clients
• cache local
• middleware
architecture
• libs padronizadas
• short stacks
• evented servers
• libs padronizadas
• good TTL strategy
• middleware
architecture
• caches
• HTTP plumbing

78. • Lei de Postel
• Seja conservador no que faz, seja liberal no que você aceita dos outros
• REST é uma arquitetura de longo prazo
• Defenda com todas as suas forças:
• seus metadados (recursos)
• sua interface
• Documentação é essencial
• Independência de desenvolvimento dos nós tem
suas desvantagens
• medir/monitorar o desempenho é importantíssimo

79. Assumimos que nossa arquitetura está válida.

80. necessidades
atendidas
custo
aceitável
+ * ß
MTRH
mas...

81. e quando REST não
for suficiente?

82. não use REST

83. Os responsáveis

84. PERGUNTAS ?

85. engineering.abril.com.br
digital.abril.com.br
Obrigado!
David Robert