Modelagem de REST

[Daniel Moreira Yokoyama]

Olá, pessoal.

Já tem um tempinho que eu venho pensando sobre o assunto, tendo que lidar com esse tipo de questão aqui e queria coletar os feedbacks de vocês.

Bem, se você opta por REST, e quiser fazer as coisas "by the book", você acaba correndo atrás de um modelo de recursos http-compliant, o que é lindo... mas pouco vantajoso já que nem tudo se resume a Post, Get, Put e Delete de recursos.

Quando você está modelando o sistema sempre encontra uma forte tendência a encontrar no caminho comandos mais complexos que isso, ou interações não lidam com algo facilmente concebido como recurso, o que pode levar a longas discussões até chegar num modelo aceitável de recurso que sirva para o que estamos tentando fazer, mas que não é lá bem algo que nós acabaríamos chamando de "bacana".

Um dos exemplos é a autenticação do usuário, que num dado momento ficava no recurso POST: users/login... e que não é por definição um recurso, mas sim um rpc. E ficávamos descontentes pelo fato de não ser exatamente um recurso no sentido de manter o http compliance. Até que remodelamos e chegamos em GET: /sessions, o que ajudou a chegarmos em um "recurso" propriamente dito... mas ficou esquisito o processo de autenticação ser um Post de um recurso que na verdade é gerenciado pelo servidor.

Outras questões tiveram o mesmo efeito, como criar uma assinatura para um usuário ser um processo que requer outros recursos envolvidos (endereço e informações de pagamento) e tudo isso tava sendo resolvido com um POST: /users/self/subscriptions?accessToken=XXXXX

Sempre tentando entender como considerar a participação de dos dados de pagamento e endereço (que pertencem ao User, e não à subscription) mas sem que o processo de subscription fizesse 3 roundtrips pro server (um post em /users/self/addresses, outro em /users/self/paymentInfo e o terceiro em users/self/subscriptions).

Como vocês lidam com isso? Eu costumo ser um pouco chato quando vejo coisas que não me soam bem... mas ao mesmo tempo, se não há muito valor em fazer diferente, acabo aceitando a solução. Mas gostaria de coletar feedbacks pra saber se alguém já pensou em boas alternativas para lidar com essas coisas.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Sidney Lima Filho]

Daniel, quando o paradigma é REST, eu geralmente paro de pensar como uma linguagem imperativa e penso de uma forma declarativa. 

Neste caso vamos supor um acesso a um prédio. Você chega numa portaria e fala "GET /CasaDoJoão" então o porteiro responde dizendo "403 Access Forbidden: Nome, ID e endereço please", então o que fazemos? "POST /Porteiro {nome:'', ... }", então porteiro nos retorna um crachá "200 OK: Token=XXXXX-XXXXX-XXXXX-XXXXX-XXXXX "

Fez sentido o que falei?

[Daniel Moreira Yokoyama]

Nenhum... rs...

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

[Daniel Moreira Yokoyama]

Post no recurso porteiro retornando um recurso crachá?

Faz sentido pra você?

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[CassioT]

Eu também tenho esses problemas. No meu caso, como o sistema é para
minha empresa eu parei de me preocupar tanto. Não tento seguir o REST
à risca porque não achei um modo de fazer isso que me agradasse 100%.
Sem contar que não implementei o tal HATEOAS.

Por esses motivos nem digo mais que trabalho com REST e sim com uma
api baseada no protocolo http.

Eu concordo, dar post em /users/login não seria certo, mas qual seria
o jeito certo? Eu não faço assim mas também não sei qual é o jeito
certo de se fazer.

Uma coisa que percebi no seu exemplo é que você passa o token de
autorização como query string. É isso mesmo? Eu passo como cabeçalho.

Abraços,

Cassio Tavares

On Apr 26, 10:24 am, Daniel Moreira Yokoyama

> @dmyokohttp://twitter.com/dmyoko
>
> Blogs:
> Getting Sharper (C#, Arquitetura de Software e outras coisas mais)http://gettingsharper.wordpress.com/

[CassioT]

Concordo. POST em /porteiro nos leva a pensar que você está
cadastrando um porteiro.

Abraços

On Apr 26, 4:00 pm, Daniel Moreira Yokoyama

<moreira.yokoy...@gmail.com> wrote:
> Post no recurso porteiro retornando um recurso crachá?
>
> Faz sentido pra você?
>
> Atenciosamente,
>
> Daniel Moreira Yokoyama.

> @dmyokohttp://twitter.com/dmyoko
>
> Blogs:
> Getting Sharper (C#, Arquitetura de Software e outras coisas mais)http://gettingsharper.wordpress.com/
>
> Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)http://eisocristo.wordpress.com

>
> Stay Sharp!
>
> Em 26 de abril de 2012 15:58, Daniel Moreira Yokoyama <

> moreira.yokoy...@gmail.com> escreveu:

>
>
>
>
>
>
>
> > Nenhum... rs...
>
> > Atenciosamente,
>
> > Daniel Moreira Yokoyama.
> > @dmyoko
> >http://twitter.com/dmyoko
>
> > Blogs:
> > Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
> >http://gettingsharper.wordpress.com/
>
> > Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)
> >http://eisocristo.wordpress.com
>
> > Stay Sharp!
>

> >>> /users/self/subscriptions?**accessToken=XXXXX

>
> >>> Sempre tentando entender como considerar a participação de dos dados de
> >>> pagamento e endereço (que pertencem ao User, e não à subscription) mas sem
> >>> que o processo de subscription fizesse 3 roundtrips pro server (um post em
> >>> /users/self/addresses, outro em /users/self/paymentInfo e o terceiro em
> >>> users/self/subscriptions).
>
> >>> Como vocês lidam com isso? Eu costumo ser um pouco chato quando vejo
> >>> coisas que não me soam bem... mas ao mesmo tempo, se não há muito valor em
> >>> fazer diferente, acabo aceitando a solução. Mas gostaria de coletar
> >>> feedbacks pra saber se alguém já pensou em boas alternativas para lidar com
> >>> essas coisas.
>
> >>> Atenciosamente,
>
> >>> Daniel Moreira Yokoyama.
> >>> @dmyoko
> >>>http://twitter.com/dmyoko
>
> >>> Blogs:
> >>> Getting Sharper (C#, Arquitetura de Software e outras coisas mais)

> >>>http://gettingsharper.**wordpress.com/<http://gettingsharper.wordpress.com/>

>
> >>> Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

> >>>http://eisocristo.wordpress.**com<http://eisocristo.wordpress.com/>

[Daniel Moreira Yokoyama]

Na verdade o accessToken vai de acordo com a chamada... no get é na querystring, óbvio... no post é no form... mas já estamos discutindo colocar ele no header, o problema é a quebra de compatibilidade.

Mesmo pensando em uma api baseada em http, a modelagem de recurso é muito mais ligada ao http em si do que ao rest (na verdade, o rest é baseado ao http, daí o uso de recursos).

No caso da empresa, a idéia é ter uma api que sirva para que desenvolvedores possam usá-la para criar suas próprias aplicações.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

>
> Stay Sharp!

[CassioT]

> Na verdade o accessToken vai de acordo com a chamada... no get é na
> querystring, óbvio... no post é no form... mas já estamos discutindo
> colocar ele no header, o problema é a quebra de compatibilidade.

Pois é. Eu não sei como você está fazendo aí, mas no meu caso, seu
passasse no post, receberia o token no método de destino em forma de
parâmetro. Isso obrigaria ter esse parâmetro em todos os métodos. Como
passo no header eu faço isso logo que recebo a requisição independente
do tipo. Mas quebrar compatibilidade é foda mesmo.

> Mesmo pensando em uma api baseada em http, a modelagem de recurso é muito
> mais ligada ao http em si do que ao rest (na verdade, o rest é baseado ao
> http, daí o uso de recursos).

Se fosse assim as url's de 99% dos aplicativos estariam
conceitualmente erradas. Na verdade elas não estão se olharmos dentro
do contexto em que rodam hoje. Na minha opinião http não obriga a
trabalhar com recursos. É só um protocolo que te permite trabalhar
assim se quiser.

Abraços,

On Apr 26, 4:05 pm, Daniel Moreira Yokoyama

<moreira.yokoy...@gmail.com> wrote:
> Na verdade o accessToken vai de acordo com a chamada... no get é na
> querystring, óbvio... no post é no form... mas já estamos discutindo
> colocar ele no header, o problema é a quebra de compatibilidade.
>
> Mesmo pensando em uma api baseada em http, a modelagem de recurso é muito
> mais ligada ao http em si do que ao rest (na verdade, o rest é baseado ao
> http, daí o uso de recursos).
>
> No caso da empresa, a idéia é ter uma api que sirva para que
> desenvolvedores possam usá-la para criar suas próprias aplicações.
>
> Atenciosamente,
>
> Daniel Moreira Yokoyama.

> @dmyokohttp://twitter.com/dmyoko
>
> Blogs:
> Getting Sharper (C#, Arquitetura de Software e outras coisas mais)http://gettingsharper.wordpress.com/
>
> Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)http://eisocristo.wordpress.com
>
> Stay Sharp!
>

> > > Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
> >http://gettingsharper.wordpress.com/
>
> > > Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)
> >http://eisocristo.wordpress.com
>
> > > Stay Sharp!
>

[Breno Ferreira]

Realmente, fazer um POST para /users/login não faz muito sentido pq externamente dá a impressão de que uma conta de usuario está sendo criada.

Mas, por exemplo, um POST para /auth/accesstoken seria apropriado, pois o servidor estaria criando um token para autenticação de usuarios. O resultado do post poderia ser um 200 ou 201 com o AccessToken no content da Response.

O que acha?

Breno Ferreira
Twitter: @breno_ferreira
Blog: http://brenoferreira.wordpress.com

---

Date: Thu, 26 Apr 2012 16:05:33 -0300
Subject: Re: [dotnetarchitects] Re: Modelagem de REST
From: moreira....@gmail.com
To: dotnetar...@googlegroups.com

[Daniel Moreira Yokoyama]

Eu acho que quem cria o token é o server, e não o client... não faz sentido pra mim fazer o post de um accessToken, se não é você que vai criá-lo.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[CassioT]

Quem sabe /auth/accesstokenrequest então? hauahau

On Apr 26, 4:48 pm, Daniel Moreira Yokoyama

<moreira.yokoy...@gmail.com> wrote:
> Eu acho que quem cria o token é o server, e não o client... não faz sentido
> pra mim fazer o post de um accessToken, se não é você que vai criá-lo.
>
> Atenciosamente,
>
> Daniel Moreira Yokoyama.

> @dmyokohttp://twitter.com/dmyoko
>
> Blogs:
> Getting Sharper (C#, Arquitetura de Software e outras coisas mais)http://gettingsharper.wordpress.com/
>
> Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)http://eisocristo.wordpress.com
>
> Stay Sharp!
>

> Em 26 de abril de 2012 16:45, Breno Ferreira

> <bferre...@windowslive.com>escreveu:

>
>
>
>
>
>
>
> >  Realmente, fazer um POST para /users/login não faz muito sentido pq
> > externamente dá a impressão de que uma conta de usuario está sendo criada.
>
> > Mas, por exemplo, um POST para /auth/accesstoken seria apropriado, pois o
> > servidor estaria criando um token para autenticação de usuarios. O
> > resultado do post poderia ser um 200 ou 201 com o AccessToken no content da
> > Response.
>
> > O que acha?
>
> > Breno Ferreira

> > Twitter: @breno_ferreira <http://twitter.com/breno_ferreira>
> > Blog:http://brenoferreira.wordpress.com
>
> > ------------------------------

> > Date: Thu, 26 Apr 2012 16:05:33 -0300
> > Subject: Re: [dotnetarchitects] Re: Modelagem de REST

> > From: moreira.yokoy...@gmail.com

> > To: dotnetar...@googlegroups.com
>
> > Na verdade o accessToken vai de acordo com a chamada... no get é na
> > querystring, óbvio... no post é no form... mas já estamos discutindo
> > colocar ele no header, o problema é a quebra de compatibilidade.
>
> > Mesmo pensando em uma api baseada em http, a modelagem de recurso é muito
> > mais ligada ao http em si do que ao rest (na verdade, o rest é baseado ao
> > http, daí o uso de recursos).
>
> > No caso da empresa, a idéia é ter uma api que sirva para que
> > desenvolvedores possam usá-la para criar suas próprias aplicações.
>
> > Atenciosamente,
>
> > Daniel Moreira Yokoyama.
> > @dmyoko
> >http://twitter.com/dmyoko
>
> > Blogs:
> > Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
> >http://gettingsharper.wordpress.com/
>
> > Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)
> >http://eisocristo.wordpress.com
>
> > Stay Sharp!
>

> > > Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
> >http://gettingsharper.wordpress.com/
>
> > > Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)
> >http://eisocristo.wordpress.com
>
> > > Stay Sharp!
>

[Sidney Lima Filho]

Pessoal, POST em /porteiro faz todo sentido para mim quando falamos de REST, POST não é SAVE, nem UPDATE, nem INSERT. POST é postar, enviar, remeter.

Não podemos arquitetar uma solução REST pensando em CRUD. A diferença entre REST e RPC por exemplo é apenas conceitual. O REST foca que no protocolo HTTP fique o estado, enquanto no RPC não interessa quem irá representar o estado o foco são nas ações.

http://xxxxx/porteiro/pegarCracha é RPC pois você não acessa um recurso mas executa uma ação e portanto não importaria se você está chamando pegarCrachá com GET, POST, PUT, DELETE, PATCH, OPTIONS, etc.

Da mesma forma a URL não é uma representação de orientação a objeto "/objeto/ação".

Em REST o foco é na representação de estado, então POST em /porteiro não se traduz em "INSERT dbo.Porteiros (...) VALUES (...)", mas se traduz como "Enviar algo para o recurso Porteiro", se a implementação de POST para /porteiro é INSERT ou é autenticação depende de como você escolhe implementar.

Da mesma forma quando apresentamos uma url roteada no ASP.NET MVC, para alguém iniciante de desenvolvimento web, dizendo "/posts/123/" ele irá achar que estamos querendo a pasta "123" dentro da pasta "posts", mas estamos querendo algo parecido com posts.aspx?id=123

Tudo é uma forma de como se pensa a arquitetura.

[Daniel Moreira Yokoyama]

Sidney, 

Você não entendeu.

Você está "postando" um recurso Porteiro, colocando dados de credenciais e retornando um recurso "Crachá"...

Se vc faz um Post em Porteiro, você está literalmente postando um recurso porteiro, e com certeza ele não tem informações de credenciais do visitante... ele tem informações do porteiro.

Eu entendo que POST, GET, PUT e DELETE, não são exatamente CRUD, mas ao mesmo tempo, a relação ainda existe em algum nível... POST em um recurso é de fato a declaração de que estou criando algo e que o servidor vai me dizer "Criado em http://enderecotal/recursotal/idtal" (basta estudar um pouco sobre como o http funciona).

Não signifca mesmo que será um insert em dbo.tb_porteiros... mas significa que o recurso porteiro está criado e será mantido na url específica. PUT é a mesma coisa, porém é você que define a url, e não o servidor. Então se você reparar bem, a diferença disso pra CRUD existe, mas é sutil (por isso a dificuldade que muita gente tem de entender... pq no fundo a semelhança entre as duas continua sendo bem grande de forma que é muito difícil não se fazer um de-para).

O que zoa toda a bagaça no seu esquema é fazer POST em porteiro (um recurso) usando dados que não são do recurso porteiro (conceitualmente falando) e respondendo com dados de outro recurso (crachá).

Qual vai ser o resultado? 201 com uma url para quem? Pro porteiro? Pro crachá? 

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Sidney Lima Filho]

Entendi Daniel.

Então deixa eu recomeçar, partindo do pressuposto que ao acessar a url "/CasaDoJoão" e receber um 403, então o cliente deve acessar via "GET" uma url "/token" para receber suas credenciais e então tentar acessar "/CasaDoJoao" novamente correto?

O que você questiona é que não faz sentido fazer POST no "/token" (que eu concordo) mas e se for GET?

Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitects+unsubscribe@googlegroups.com

[Juan Lopes]

E se a autenticação não estiver representada por domínio nenhum? E se o porteiro for somente infra?

O HTTP define tantas formas não obstrusivas de fazer autenticação que geralmente eu não me preocupo em modelar isso.

O sistema atual que estou desenvolvendo disponibiliza uma API rest. E fazer login é simplesmente usar os recursos normalmente enviando headers de basic http auth ou via client ceritificates.

https://github.com/intelie/lognit-cli/blob/master/src/main/java/net/intelie/lognit/cli/http/RestClientImpl.java#L62

Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com

Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

--
https://github.com/juanplopes

[CassioT]

O problema que vejo de fazer com GET é que você vai ter que passar as
credenciais via query string. Pouco seguro. Nesse caso eu prefiro
fazer o POST mesmo que pareça errado.

E agora pensei uma coisa aqui Daniel. Você passa o token do GET na
url. Não acha que está muito fácil de ler esse token?

On 26 abr, 19:51, Sidney Lima Filho <sidney.fi...@perto.vc> wrote:
> Entendi Daniel.
>
> Então deixa eu recomeçar, partindo do pressuposto que ao acessar a url
> "/CasaDoJoão" e receber um 403, então o cliente deve acessar via "GET" uma
> url "/token" para receber suas credenciais e então tentar acessar
> "/CasaDoJoao" novamente correto?
>
> O que você questiona é que não faz sentido fazer POST no "/token" (que eu
> concordo) mas e se for GET?
>
> Em quinta-feira, 26 de abril de 2012 17h15min18s UTC-3, @dmyoko escreveu:
>
>
>
>
>
> > Sidney,
>
> > Você não entendeu.
>
> > Você está "postando" um recurso Porteiro, colocando dados de credenciais e
> > retornando um recurso "Crachá"...
>
> > Se vc faz um Post em Porteiro, você está literalmente postando um recurso
> > porteiro, e com certeza ele não tem informações de credenciais do
> > visitante... ele tem informações do porteiro.
>
> > Eu entendo que POST, GET, PUT e DELETE, não são exatamente CRUD, mas ao
> > mesmo tempo, a relação ainda existe em algum nível... POST em um recurso é
> > de fato a declaração de que estou criando algo e que o servidor vai me

> > dizer "Criado emhttp://enderecotal/recursotal/idtal" (basta estudar um

> > pouco sobre como o http funciona).
>
> > Não signifca mesmo que será um insert em dbo.tb_porteiros... mas significa
> > que o recurso porteiro está criado e será mantido na url específica. PUT é
> > a mesma coisa, porém é você que define a url, e não o servidor. Então se
> > você reparar bem, a diferença disso pra CRUD existe, mas é sutil (por isso
> > a dificuldade que muita gente tem de entender... pq no fundo a semelhança
> > entre as duas continua sendo bem grande de forma que é muito difícil não se
> > fazer um de-para).
>
> > O que zoa toda a bagaça no seu esquema é fazer POST em porteiro (um
> > recurso) usando dados que não são do recurso porteiro (conceitualmente
> > falando) e respondendo com dados de outro recurso (crachá).
>
> > Qual vai ser o resultado? 201 com uma url para quem? Pro porteiro? Pro
> > crachá?
>
> > Atenciosamente,
>
> > Daniel Moreira Yokoyama.
> > @dmyoko
> >http://twitter.com/dmyoko
>
> > Blogs:
> > Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
> >http://gettingsharper.wordpress.com/
>
> > Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)
> >http://eisocristo.wordpress.com
>
> > Stay Sharp!
>

> > Em 26 de abril de 2012 16:54, Sidney Lima Filho <sidney.fi...@perto.vc>escreveu:
>
> >> Pessoal, POST em /porteiro faz todo sentido para mim quando falamos de
> >> REST, POST não é SAVE, nem UPDATE, nem INSERT. POST é postar, enviar,
> >> remeter.
>
> >> Não podemos arquitetar uma solução REST pensando em CRUD. A diferença
> >> entre REST e RPC por exemplo é apenas conceitual. O REST foca que no
> >> protocolo HTTP fique o estado, enquanto no RPC não interessa quem irá
> >> representar o estado o foco são nas ações.
>

> >>http://xxxxx/porteiro/pegarCrachaé RPC pois você não acessa um recurso

> >>> /users/self/subscriptions?**accessToken=XXXXX

>
> >>> Sempre tentando entender como considerar a participação de dos dados de
> >>> pagamento e endereço (que pertencem ao User, e não à subscription) mas sem
> >>> que o processo de subscription fizesse 3 roundtrips pro server (um post em
> >>> /users/self/addresses, outro em /users/self/paymentInfo e o terceiro em
> >>> users/self/subscriptions).
>
> >>> Como vocês lidam com isso? Eu costumo ser um pouco chato quando vejo
> >>> coisas que não me soam bem... mas ao mesmo tempo, se não há muito valor em
> >>> fazer diferente, acabo aceitando a solução. Mas gostaria de coletar
> >>> feedbacks pra saber se alguém já pensou em boas alternativas para lidar com
> >>> essas coisas.
>
> >>> Atenciosamente,
>
> >>> Daniel Moreira Yokoyama.
> >>> @dmyoko
> >>>http://twitter.com/dmyoko
>
> >>> Blogs:
> >>> Getting Sharper (C#, Arquitetura de Software e outras coisas mais)

> >>>http://gettingsharper.**wordpress.com/<http://gettingsharper.wordpress.com/>

>
> >>> Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

> >>>http://eisocristo.wordpress.**com<http://eisocristo.wordpress.com/>

>
> >>> Stay Sharp!
>
> >>>   --
> >> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> >> hospedado no Google Groups.

> >> Para postar envie uma mensagem para dotnetar...@googlegroups.com

> >> Para sair do grupo envie uma mensagem para

> >> dotnetarchitec...@googlegroups.com

[Sidney Lima Filho]

Juan, mas nesse casso ao passar via basic-auth é bem inseguro pois passar usuário e senha em base64 é bem frágil. Com relação ao client-certificate você de certa forma já autenticou o cara, pois para ter um certificado houve alguma autenticação.

https://github.com/juanplopes

[Juan Lopes]

E passar no body do post em plain text não é?

Para isso existe https.

Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com

Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

--
https://github.com/juanplopes

[Sidney Lima Filho]

Sim, mas a cada acesso ao recurso iria sempre enviar usuário e senha? Acho que não é o ponto que o Daniel abordou.

[Juan Lopes]

Além do mais, client certificates funcionam quando a autenticação é passiva (algo comum em empresas). E é uma conveniencia para o cara não ter que ficar digitando a senha o tempo todo.

Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com

Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

--
https://github.com/juanplopes

[Sidney Lima Filho]

Cassio, não precisa enviar as credenciais por querystring não, pode ser enviado por request headers. Inclusive se for usar basic-auth enviaria o usuário e senha com um request header "Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==" por exemplo.

O ponto é não ficar enviando uma string como essa o tempo todo. Então o Daniel pensou em uma solução de autorização.

Na solução de autorização que falei ele enviaria um GET para um recurso token, por exemplo, enviando usuário e senha na base64 como request header. O server enviaria um token e com este token seria enviado a cada requisição também como request header.

O que acha Daniel?

> >> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com

> >> Para sair do grupo envie uma mensagem para

> >> dotnetarchitects+unsubscribe@googlegroups.com

> >> Para mais opções visite o grupo em
> >>http://groups.google.com/group/dotnetarchitects?hl=pt-br

> >> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com

> >> Para sair do grupo envie uma mensagem para

> >> dotnetarchitects+unsubscribe@googlegroups.com

> >> Para mais opções visite o grupo em
> >>http://groups.google.com/group/dotnetarchitects?hl=pt-br

> >> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com

> >> Para sair do grupo envie uma mensagem para

> >> dotnetarchitects+unsubscribe@googlegroups.com

> >> Para mais opções visite o grupo em
> >>http://groups.google.com/group/dotnetarchitects?hl=pt-br

> >> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com

> >> Para sair do grupo envie uma mensagem para

> >> dotnetarchitects+unsubscribe@googlegroups.com

[Sidney Lima Filho]

Como seria uma solução de client-certificates para um usuário comum? 

[Juan Lopes]

Sidney, exatamente assim que 99% dos sistemas web fazem autenticação. O único ponto é que esse header onde você coloca esse token é chamado de cookie.

Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com

Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

--
https://github.com/juanplopes

[Juan Lopes]

Depende do que você chama de usuário comum. Se os seus recursos só vão ser acessados via browser ou chamadas xhr, client certificates mais atrapalham do que ajudam.

Mas no meu caso, por exemplo, eu tenho uma ferramenta de linha de comando, operada por pessoas que estão acostumadas a acessar servidores e usar o git através de chaves rsa. Client certificates fazem todo o sentido nesse caso.

Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com

Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

--
https://github.com/juanplopes

[Sidney Lima Filho]

Ahhhh se chamam isso de biscoito é outra história... :-)

https://github.com/juanplopes

[Sidney Lima Filho]

É verdade neste cenário mais atrapalha que ajuda.

Eu já implementei uma coisa que no mundo .NET chamamos de HttpModule que a cada request ele pegava o "biscoito" e fazia uma pergunta simples, é guid e está válido então deixa passar. É usuário/senha na base64 então autentica o cara e manda um guid no response header. Assim para cada recurso/url que o client enviava já fazia o papel do "porteiro" e o acesso ao recurso era transparente.

[CassioT]

Pois é Sidney. O que estou falando é que ele tá enviando esse token na
url.

Eu sei que não precisa mas é o que está acontecendo. Eu acho :)

> > > >>http://xxxxx/porteiro/pegarCrachaéRPC pois você não acessa um

> > > >> Para postar envie uma mensagem para dotnetar...@googlegroups.com

> > > >> Para sair do grupo envie uma mensagem para

> > > >> dotnetarchitec...@googlegroups.com

> > > >> Para mais opções visite o grupo em
> > > >>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> Em quinta-feira, 26 de abril de 2012 20h20min10s UTC-3, CassioT escreveu:
>
>
>
>
>
>
>
>
>
> > O problema que vejo de fazer com GET é que você vai ter que passar as
> > credenciais via query string. Pouco seguro. Nesse caso eu prefiro
> > fazer o POST mesmo que pareça errado.
>
> > E agora pensei uma coisa aqui Daniel. Você passa o token do GET na
> > url. Não acha que está muito fácil de ler esse token?
>
> > On 26 abr, 19:51, Sidney Lima Filho <sidney.fi...@perto.vc> wrote:
> > > Entendi Daniel.
>
> > > Então deixa eu recomeçar, partindo do pressuposto que ao acessar a url
> > > "/CasaDoJoão" e receber um 403, então o cliente deve acessar via "GET"
> > uma
> > > url "/token" para receber suas credenciais e então
>

> ...
>
> read more »

[CassioT]

Juan, pode ser também.

Eu não sei se pro Daniel também mas o problema não é só com o login.
Há diversas outras operações que caem no mesmo problema. É difícil de
representa-las em alguns casos. Como ficaria na sua opinião o cálculo
de imposto de uma nota fiscal?

POST ../nota/1/calcularimposto
POST ../calculadora/imposto e o id da nota vai no corpo

Tô inventando aqui só pra ilustrar mesmo.

On Apr 26, 8:12 pm, Juan Lopes <m...@juanlopes.net> wrote:
> E se a autenticação não estiver representada por domínio nenhum? E se o
> porteiro for somente infra?
>
> O HTTP define tantas formas não obstrusivas de fazer autenticação que
> geralmente eu não me preocupo em modelar isso.
>
> O sistema atual que estou desenvolvendo disponibiliza uma API rest. E fazer
> login é simplesmente usar os recursos normalmente enviando headers de basic
> http auth ou via client ceritificates.
>

> https://github.com/intelie/lognit-cli/blob/master/src/main/java/net/i...

>
> On Thu, Apr 26, 2012 at 7:51 PM, Sidney Lima Filho <sidney.fi...@perto.vc>wrote:
>
>
>
>
>
>
>
>
>
> > Entendi Daniel.
>
> > Então deixa eu recomeçar, partindo do pressuposto que ao acessar a url
> > "/CasaDoJoão" e receber um 403, então o cliente deve acessar via "GET" uma
> > url "/token" para receber suas credenciais e então tentar acessar
> > "/CasaDoJoao" novamente correto?
>
> > O que você questiona é que não faz sentido fazer POST no "/token" (que eu
> > concordo) mas e se for GET?
>
> > Em quinta-feira, 26 de abril de 2012 17h15min18s UTC-3, @dmyoko escreveu:
>
> >> Sidney,
>
> >> Você não entendeu.
>
> >> Você está "postando" um recurso Porteiro, colocando dados de credenciais
> >> e retornando um recurso "Crachá"...
>
> >> Se vc faz um Post em Porteiro, você está literalmente postando um recurso
> >> porteiro, e com certeza ele não tem informações de credenciais do
> >> visitante... ele tem informações do porteiro.
>
> >> Eu entendo que POST, GET, PUT e DELETE, não são exatamente CRUD, mas ao
> >> mesmo tempo, a relação ainda existe em algum nível... POST em um recurso é
> >> de fato a declaração de que estou criando algo e que o servidor vai me

> >> dizer "Criado emhttp://enderecotal/recursotal/**idtal<http://enderecotal/recursotal/idtal>"

> >> (basta estudar um pouco sobre como o http funciona).
>
> >> Não signifca mesmo que será um insert em dbo.tb_porteiros... mas
> >> significa que o recurso porteiro está criado e será mantido na url
> >> específica. PUT é a mesma coisa, porém é você que define a url, e não o
> >> servidor. Então se você reparar bem, a diferença disso pra CRUD existe, mas
> >> é sutil (por isso a dificuldade que muita gente tem de entender... pq no
> >> fundo a semelhança entre as duas continua sendo bem grande de forma que é
> >> muito difícil não se fazer um de-para).
>
> >> O que zoa toda a bagaça no seu esquema é fazer POST em porteiro (um
> >> recurso) usando dados que não são do recurso porteiro (conceitualmente
> >> falando) e respondendo com dados de outro recurso (crachá).
>
> >> Qual vai ser o resultado? 201 com uma url para quem? Pro porteiro? Pro
> >> crachá?
>
> >> Atenciosamente,
>
> >> Daniel Moreira Yokoyama.
> >> @dmyoko
> >>http://twitter.com/dmyoko
>
> >> Blogs:
> >> Getting Sharper (C#, Arquitetura de Software e outras coisas mais)

> >>http://gettingsharper.**wordpress.com/<http://gettingsharper.wordpress.com/>

>
> >> Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

> >>http://eisocristo.wordpress.**com<http://eisocristo.wordpress.com/>
>
> >> Stay Sharp!

>
> >> Em 26 de abril de 2012 16:54, Sidney Lima Filho <sidney.fi...@perto.vc>escreveu:
>
> >>> Pessoal, POST em /porteiro faz todo sentido para mim quando falamos de
> >>> REST, POST não é SAVE, nem UPDATE, nem INSERT. POST é postar, enviar,
> >>> remeter.
>
> >>> Não podemos arquitetar uma solução REST pensando em CRUD. A diferença
> >>> entre REST e RPC por exemplo é apenas conceitual. O REST foca que no
> >>> protocolo HTTP fique o estado, enquanto no RPC não interessa quem irá
> >>> representar o estado o foco são nas ações.
>

> >>>http://xxxxx/porteiro/**pegarCracha<http://xxxxx/porteiro/pegarCracha>é RPC pois você não acessa um recurso mas executa uma ação e portanto não

> >>>> /users/self/subscriptions?**acce**ssToken=XXXXX

>
> >>>> Sempre tentando entender como considerar a participação de dos dados de
> >>>> pagamento e endereço (que pertencem ao User, e não à subscription) mas sem
> >>>> que o processo de subscription fizesse 3 roundtrips pro server (um post em
> >>>> /users/self/addresses, outro em /users/self/paymentInfo e o terceiro em
> >>>> users/self/subscriptions).
>
> >>>> Como vocês lidam com isso? Eu costumo ser um pouco chato quando vejo
> >>>> coisas que não me soam bem... mas ao mesmo tempo, se não há muito valor em
> >>>> fazer diferente, acabo aceitando a solução. Mas gostaria de coletar
> >>>> feedbacks pra saber se alguém já pensou em boas alternativas para lidar com
> >>>> essas coisas.
>
> >>>> Atenciosamente,
>
> >>>> Daniel Moreira Yokoyama.
> >>>> @dmyoko
> >>>>http://twitter.com/dmyoko
>
> >>>> Blogs:
> >>>> Getting Sharper (C#, Arquitetura de Software e outras coisas mais)

> >>>>http://gettingsharper.**wordpres**s.com/<http://gettingsharper.wordpress.com/>

>
> >>>> Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

> >>>>http://eisocristo.wordpress.**co**m<http://eisocristo.wordpress.com/>

>
> >>>> Stay Sharp!
>
> >>>>   --
> >>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> >>> hospedado no Google Groups.

> >>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.**com<dotnetar...@googlegroups.com>
> >>> Para sair do grupo envie uma mensagem para dotnetarchitects+unsubscribe@
> >>> **googlegroups.com <dotnetarchitects%2Bunsu...@googlegroups.com>
> >>> Para mais opções visite o grupo emhttp://groups.google.com/**
> >>> group/dotnetarchitects?hl=pt-**br<http://groups.google.com/group/dotnetarchitects?hl=pt-br>

[Pedro Reys]

Cassio, o problema aqui está no design da sua api.

Esse ai é um exemplo canônico de rpc. Qual o contexto em que você faria uma chamada pra calcular um imposto? Pensando como resources faz mais sentido você criar um recurso FechamentoDePedido e neste processo de criaçao do fechamento do pedido, realizar o cálculo do imposto e gerar a nota, não faz?

Eu prefiro desenhar minha api sem primeiramente sem pensar em verbos e urls. Desenhe primeiro a máquina de estados da sua api. Com isso feito, fica mais fácil depois ver qual serão as urls e verbos que atenderão suas necessidades.

Daniel,

Como o Juan disse, autenticação é algo que você pode resolver via http mesmo. Seja via Basic Auth, que eu vi que você tem receio, embora se você usar https resolve seu problema. Vc pode ainda usar digest ou, se fizer sentido no seu cenário, oAuth.

E, pra enviar o token de autenticação tenho visto gente usando custom headers, algo como X-ApiToken, ao invés de mandar via query string ou no body.



Sent from my PenseBem

[CassioT]

Pedro, só uma correção. Essa não é minha api, é só um exemplo que eu
dei.

Mas vamos supor que fosse minha api. Mesmo assim eu poderia ter n
motivos pra ter o cálculo do imposto sem ter fechamento de pedido.
Quem disse que o cálculo é feito no fechamento? E por aí vai.

Abraços,

On Apr 27, 12:24 am, Pedro Reys <pedror...@gmail.com> wrote:
> Cassio, o problema aqui está no design da sua api.
>
> Esse ai é um exemplo canônico de rpc. Qual o contexto em que você faria uma chamada pra calcular um imposto? Pensando como resources faz mais sentido você criar um recurso FechamentoDePedido e neste processo de criaçao do fechamento do pedido, realizar o cálculo do imposto e gerar a nota, não faz?
>
> Eu prefiro desenhar minha api sem primeiramente sem pensar em verbos e urls. Desenhe primeiro a máquina de estados da sua api. Com isso feito, fica mais fácil depois ver qual serão as urls e verbos que atenderão suas necessidades.
>
> Daniel,
>
> Como o Juan disse, autenticação é algo que você pode resolver via http mesmo. Seja via Basic Auth, que eu vi que você tem receio, embora se você usar https resolve seu problema. Vc pode ainda usar digest ou, se fizer sentido no seu cenário, oAuth.
>
> E, pra enviar o token de autenticação tenho visto gente usando custom headers, algo como X-ApiToken, ao invés de mandar via query string ou no body.
>
> Sent from my PenseBem
>

> ...
>
> read more »

[dm.ga...@gmail.com]

Cassio,

Entrando nesse exemplo, acho ninguém só faz um calculo de imposto. Ela normalmente está dentro de outra rotina, por exemplo FecharPedido, PréviaDoPedido (não achei um nome expressivo), ValidaCarrinho and so on. 

Acho que ficaria meio estranho dividir essa lógica entre o serviço e cliente da API. 

[]

Deivison M. Gandini
dm.ga...@gmail.com | msn: dm_ga...@hotmail.com
Before printing, think about your responsibility and commitment to the ENVIRONMENT!
Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO AMBIENTE!

2012/4/27 CassioT <cas...@gmail.com>

Para postar envie uma mensagem para dotnetar...@googlegroups.com

[Daniel Moreira Yokoyama]

Eu até concordo Juan. Mas como o Cassio disse a questão não eh somente login.

[Pedro Reys]

Daniel, voce pode nos dar exemplo de um cenario em que voce esteja tendo problema sem ser o de login.

Esqueca verbos, urls, rotas. Qual a state machine que sua api expoe? Baseado no que eu li por aqui, acredito que o problema esteja mais no design da sua api do que no mapeamento de verbos/acoes.

O exemplo que o Cassio deu, pelo menos, mostra isso. No exemplo ele modelou uma chamada RPC, nao uma maquina de estados de recursos.

Abracoes,

- Pedro Reys

2012/4/27 Daniel Moreira Yokoyama <moreira....@gmail.com>

[CassioT]

Deivison, isso não existe. Qualquer sistema pode fazer qualquer coisa
por mais absurdo que isso parece à primeira vista.

Abraços

On Apr 27, 9:12 am, "dm.gand...@gmail.com" <dm.gand...@gmail.com>
wrote:

> Cassio,
>
> Entrando nesse exemplo, acho ninguém só faz um calculo de imposto. Ela
> normalmente está dentro de outra rotina, por exemplo FecharPedido,
> PréviaDoPedido (não achei um nome expressivo), ValidaCarrinho and so on.
> Acho que ficaria meio estranho dividir essa lógica entre o serviço e
> cliente da API.
>
> []
>
> Deivison M. Gandini

> dm.gand...@gmail.com | msn: dm_gand...@hotmail.com

> Before printing, think about your responsibility and commitment to the
> ENVIRONMENT!
> Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO
> AMBIENTE!
>

> 2012/4/27 CassioT <cass...@gmail.com>

> > > >>>>> Da mesma forma quando apresentamos uma url roteada no ASP.NETMVC, para

> ...
>
> read more »

[CassioT]

Pedro, vou usar um exemplo mais ligado ao que estou fazendo agora para
ficar mais fácil de discutirmos.

Eu tenho uma atividade e essa pode ser cancelada.

Como você mesmo ressaltou, ../atividades/1/cancelar é rpc demais.

Nesse caso, você sugere algo como ../atividades/1/cancelamento mesmo
que a ação de cancelar seja simplesmente setar um flag na atividade,
ou seja, não existe entidade de cancelamento. Assim esse recurso nem
aceitaria o método GET. É isso mesmo que quer dizer?

Esse caminho me parece bom. Minha dúvida é se dá pra seguir essa linha
no sistema todo. Você já fez?

Abraços,

On Apr 27, 10:06 am, Pedro Reys <pedror...@gmail.com> wrote:
> Daniel, voce pode nos dar exemplo de um cenario em que voce esteja tendo
> problema sem ser o de login.
>
> Esqueca verbos, urls, rotas. Qual a state machine que sua api expoe?
> Baseado no que eu li por aqui, acredito que o problema esteja mais no
> design da sua api do que no mapeamento de verbos/acoes.
>
> O exemplo que o Cassio deu, pelo menos, mostra isso. No exemplo ele modelou
> uma chamada RPC, nao uma maquina de estados de recursos.
>
> Abracoes,
>
> - Pedro Reys
>

> 2012/4/27 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>

>
>
>
>
>
>
>
> > Eu até concordo Juan. Mas como o Cassio disse a questão não eh somente
> > login.

> > Em 27/04/2012 09:13, "dm.gand...@gmail.com" <dm.gand...@gmail.com>

> > escreveu:
>
> > Cassio,
>
> >> Entrando nesse exemplo, acho ninguém só faz um calculo de imposto. Ela
> >> normalmente está dentro de outra rotina, por exemplo FecharPedido,
> >> PréviaDoPedido (não achei um nome expressivo), ValidaCarrinho and so on.
> >> Acho que ficaria meio estranho dividir essa lógica entre o serviço e
> >> cliente da API.
>
> >> []
>
> >> Deivison M. Gandini

> >> dm.gand...@gmail.com | msn: dm_gand...@hotmail.com

> >> Before printing, think about your responsibility and commitment to the
> >> ENVIRONMENT!
> >> Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO
> >> AMBIENTE!
>

> >> 2012/4/27 CassioT <cass...@gmail.com>

> >>> > >>>>> Da mesma forma quando apresentamos uma url roteada no ASP.NETMVC, para

> >>> > >>>>> alguém iniciante de desenvolvimento web, dizendo "/posts/123/"
> >>> ele irá
> >>> > >>>>> achar que estamos querendo a pasta "123" dentro da pasta
> >>> "posts", mas
> >>> > >>>>> estamos querendo algo parecido com posts.aspx?id=123
>
> >>> > >>>>> Tudo é uma forma de como se pensa a arquitetura.
>
> >>> > >>>>> Em quinta-feira, 26 de abril de 2012 10h24min22s UTC-3, @dmyoko
> >>> escreveu:
>
> >>> > >>>>>> Olá, pessoal.
>
> >>> > >>>>>> Já tem um tempinho que eu venho pensando sobre o assunto, tendo
> >>> que
> >>> > >>>>>> lidar com esse tipo de questão aqui e queria coletar os
> >>> feedbacks de vocês.
>
> >>> > >>>>>> Bem, se você opta por REST, e quiser fazer as coisas "by the
> >>> book",
> >>> > >>>>>> você acaba correndo atrás de um modelo de recursos
> >>> http-compliant, o que é
> >>> > >>>>>> lindo... mas pouco vantajoso já que nem tudo se resume a Post,
> >>> Get, Put e
> >>> > >>>>>> Delete de recursos.
>
> >>> > >>>>>> Quando você está modelando o sistema sempre
>

> ...
>
> read more »

[Pedro Reys]

Um recurso nao precisa ser algo existente no mundo real, recurso eh um conceito abstrato.

Da dissertacao: 

The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. "today's weather in Los Angeles"), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author's hypertext reference must fit within the definition of a resource. A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time.

No seu exemplo, "cancelar" eh a acao que voce quer realizar, mas pensando em "resources" pra mim faz mais sentido criar um recurso de cancelamento de atividade.

novamente, tente deixar de lado um pouco uris e verbos, pense na maquina de estados de recursos.

- Pedro Reys

2012/4/27 CassioT <cas...@gmail.com>

> ...
>
> read more »

[Sidney Lima Filho]

Pedro, no texto que mandou, a parte final diz:

"... A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time. ..."

Eu não consigo enxergar um recurso "cancelamento" ser um mapeamento conceitual para um conjunto de entidades.

Faz mais sentido para mim usar o verbo DELETE no "/atividades/1", pois no final da execução a atividade 1 estará inutilizada. E se a implementação do verbo DELETE for uma exclusão lógica numa base de dados, isso passa a ser um detalhe de implementação.

2012/4/27 CassioT <cas...@gmail.com>

Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitects+unsubscribe@googlegroups.com

[Pedro Reys]

De fato, Sidney.

Acho que sua solucao usando DELETE no resource atividades faca mais sentido.

Abracos,

- Pedro Reys

2012/4/30 Sidney Lima Filho <sidney...@perto.vc>

Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com

[CassioT]

E se você tiver as seguintes operações para implementar para uma
atividade?

-deletar
-cancelar
-cancelar temporariamente
-?

4 verbos não são suficientes para simular todas operações e não
queremos estados que sejam operações. Alguns artifícios tem que ser
criados, sejam eles parâmetros, novos estados ou qualquer outra
coisa.

O que acham?

Abraços,

On Apr 30, 2:40 pm, Sidney Lima Filho <sidney.fi...@perto.vc> wrote:
> Pedro, no texto que mandou, a parte final diz:
>
> "... A resource is a conceptual mapping to a set of entities, not the
> entity that corresponds to the mapping at any particular point in time. ..."
>
> Eu não consigo enxergar um recurso "cancelamento" ser um mapeamento
> conceitual para um conjunto de entidades.
>
> Faz mais sentido para mim usar o verbo DELETE no "/atividades/1", pois no
> final da execução a atividade 1 estará inutilizada. E se a implementação do
> verbo DELETE for uma exclusão lógica numa base de dados, isso passa a ser
> um detalhe de implementação.
>
> Em sexta-feira, 27 de abril de 2012 12h10min33s UTC-3, Pedro Reys escreveu:
>
>
>
>
>
>
>
>
>
> > Um recurso nao precisa ser algo existente no mundo real, recurso eh um
> > conceito abstrato.
>

> > Da dissertacao<http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm>
> > :
>
> > The key abstraction of information in REST is a *resource*. Any

> >> information that can be named can be a resource: a document or image, a
> >> temporal service (e.g. "today's weather in Los Angeles"), a collection of
> >> other resources, a non-virtual object (e.g. a person), and so on. In other
> >> words, any concept that might be the target of an author's hypertext
> >> reference must fit within the definition of a resource. A resource is a
> >> conceptual mapping to a set of entities, not the entity that corresponds to
> >> the mapping at any particular point in time.
>
> > No seu exemplo, "cancelar" eh a acao que voce quer realizar, mas pensando
> > em "resources" pra mim faz mais sentido criar um recurso de cancelamento de
> > atividade.
>
> > novamente, tente deixar de lado um pouco uris e verbos, pense na maquina
> > de estados de recursos.
>
> > - Pedro Reys
>

> > 2012/4/27 CassioT <cass...@gmail.com>

> ...
>
> read more »

[Mário Meyrelles]

Ahh cara, na boa, passa o que você quer fazer com a atividade via POST mesmo! Praticidade é tudo na vida.

2012/5/4 CassioT <cas...@gmail.com>

> ...
>
> read more »

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.

Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com

[CassioT]

Pois é Mário, por isso que na primeira mensagem que mandei nesse
tópico eu escrevi:

"Não tento seguir o REST à risca porque não achei um modo de fazer
isso que me agradasse 100%"

Eu já estou fazendo de um jeito que bolei aqui, mas se alguém puder
ensinar algo a mais eu aceito. rsrs

Abraços,

On May 4, 2:48 pm, Mário Meyrelles <mariomeyrel...@gmail.com> wrote:
> Ahh cara, na boa, passa o que você quer fazer com a atividade via POST
> mesmo! Praticidade é tudo na vida.
>

> 2012/5/4 CassioT <cass...@gmail.com>

> ...
>
> read more »

[CassioT]

...continuando

Principalmente se não perder praticidade. Nisso eu concordo 100% com
você.

> ...
>
> read more »

[Mário Meyrelles]

Eu tb concordo com você cara. Não dá, pra prática, pra seguir REST 100% do tempo. Acho que o maior design goal é fazer com que os clientes fiquem felizes e achem simples trabalhar com sua API. Outro design goal importante passar  o mínimo de coisas possível no POST, tipicamente, só o que mudou. Eu to trabalhando com o web api e tô quase conseguindo isso rs.

Sds,

Mário

2012/5/4 CassioT <cas...@gmail.com>

> ...
>
> read more »

[Pedro Reys]

2012/5/4 CassioT <cas...@gmail.com>

4 verbos não são suficientes para simular todas operações e não
queremos estados que sejam operações.

Cassio, nesse seu novo cenario, onde ha diferenca semantica entre os tipos de cancelamento, eu entendo que eles representem diferentes resources. Sendo assim, nao vejo problema em ter:

deletar => DELETE /atividade/1 

cancelar => POST /cancelamentoAtividade

cancelar temporatiamente => POST /cancelamentoTemporarioAtividade

Uma coisa que eu tenho curiosidade, o que voces chamam seguir RESTa risca?

[Pedro Reys]

Pensando melhor, qual a diferenca entre "Deletar", "Cancelar" ou "Cancelar temporariamente"?

Digamos que voce cancelou a atividade 1. Se eu tentar recuperar essa atividade o que acontece?

Exemplo:

(faz alguma coisa que cancela a atividade)

(...)

GET /atividade/1

o que eu recebo de volta? A atividade 1 com o status de cancelado? 404?

E se eu deletar a atividade ao inves de cancelar, o que acontece quando eu tentar fazer um GET?

- Pedro Reys

2012/5/4 Pedro Reys <pedr...@gmail.com>

[Mário Meyrelles]

Por isso que acho mais prático mandar algo no post. "Resourcificar" todos as ações de um sistema mais complexo não me parece boa coisa. Neste caso eu quero mesmo mesmo fazer um remote procedure call, pedindo algo que não é necessariamente o retorno recurso para o servidor. Quero modificá-lo de forma customizada.

Um jeito imbecil de fazer seria passar:

POST /atividades/

{id: 123; Action: "Cancel"} (pode ser tb "Pause", "Resume") e ele retornar, com 200, a atividade e o status corrente - acho mais fácil e simples de entender.

Aí poderia manter os demais verbos padrão

GET /atividades/123 - retorna 200 tb com o status que está atividade - Running | Stopped | Completed | Paused | etc...

DELETE /atividades/123 - apaga para sempre a atividade

PUT /atividades + JSON do corpo : cria um atividade e retorna um json com a atividade criada.

Sei lá, eu faria assim por enquanto - até porque, é bem fácil chamar tais métodos do jquery, do mobile, do .net, etc... 

Sds,

Mário

2012/5/4 Pedro Reys <pedr...@gmail.com>

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.

Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com

[Breno Ferreira]

Acredito que em REST, "Nouns are good, verbs are bad". Mas, há casos que voce não está expondo um recurso, e sim uma ação.

Por exemplo, na API de conversão de moeda do Google:

GET /api/convert?FROM=BRL&TO=USD&val=10

O importante é oferecer ao consumer da API algo que seja bom de se trabalhar. Por isso que é recomendavel usar substantivos para recursos, mas ocasionalmente faz mais sentido ter verbos e oferecer uma API mais familiar e natural.

Pelo menos essa é minha opinião.

Abs

Breno Ferreira
Twitter: @breno_ferreira
Blog: http://brenoferreira.wordpress.com

---

From: mariome...@gmail.com
Date: Fri, 4 May 2012 16:35:02 -0300
Subject: Re: [dotnetarchitects] Re: Modelagem de REST
To: dotnetar...@googlegroups.com

[Pedro Subutzki <Pepeu>]

Não sei se ajuda, mas segue o link para a apresentação sobre SOA (que fala bastante sobre REST) usado na pós de gestão de projetos da UNISAL:
http://jogano10.com/soa-e-rest-unisal/

Abraços,
Pedro

[CassioT]

Seguir as práticas recomendas na modelagem de um sistema desse tipo. À
risca seria algo como seguir todas ou a maioria, imho.

On May 4, 4:11 pm, Pedro Reys <pedror...@gmail.com> wrote:
> 2012/5/4 CassioT <cass...@gmail.com>

[CassioT]

Não sei. Eu inventei nesse caso. :)

Só queria criar uma hipótese onde existem várias operações.

On May 4, 4:20 pm, Pedro Reys <pedror...@gmail.com> wrote:
> Pensando melhor, qual a diferenca entre "Deletar", "Cancelar" ou "Cancelar
> temporariamente"?
>
> Digamos que voce cancelou a atividade 1. Se eu tentar recuperar essa
> atividade o que acontece?
>
> Exemplo:
>
> (faz alguma coisa que cancela a atividade)
>
> (...)
>
> GET /atividade/1
>
> o que eu recebo de volta? A atividade 1 com o status de cancelado? 404?
>
> E se eu deletar a atividade ao inves de cancelar, o que acontece quando eu
> tentar fazer um GET?
>
> - Pedro Reys
>

> 2012/5/4 Pedro Reys <pedror...@gmail.com>
>
>
>
>
>
>
>
> > 2012/5/4 CassioT <cass...@gmail.com>

[Pedro Reys]

Mesmo nessa situação hipotética, se você conseguir definir o comportamento esperado, dá pra fazermos um exercício de design da sua API. Agora, só com informações por alto, fica dificil tentar fazer algo.

Sent from my iPhone

> --
> Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.

> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com

[Pedro Reys]

E que práticas recomendadas são essas? Você pode me dar exemplos de tais práticas?

Sent from my iPhone

> --
> Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.

> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com

[Breno Ferreira]

Esse ebook dá umas dicas muito boas para um bom design de web apis REST

http://offers.apigee.com/api-design-ebook-rr/

Abs

Breno Ferreira
Twitter: @breno_ferreira
Blog: http://brenoferreira.wordpress.com

> Subject: Re: [dotnetarchitects] Re: Modelagem de REST

> From: pedr...@gmail.com
> Date: Sat, 5 May 2012 12:33:13 -0500
> To: dotnetar...@googlegroups.com

[CassioT]

Usar substantivos ao invés de verbos tá bom?

Lê o artigo que você mesmo mandou ou qualquer livro que você vai ler
um monte.

Pra mim esse tópico está encerrado. Não estamos andando mais. Se tiver
uma boa contribuição eu volto.

On May 5, 2:33 pm, Pedro Reys <pedror...@gmail.com> wrote:
> E que práticas recomendadas são essas? Você pode me dar exemplos de tais práticas?
>
> Sent from my iPhone
>

[Pedro Reys]

Cassio,

Primeiramente, me parece que você ficou incomodado com a minha pergunta. Me desculpe, de verdade. Não era essa a minha intenção. É o problema de conversar por email.

O motivo pelo qual eu perguntei sobre que melhores práticas a que você se refere é para, sinceramente, entender o que você chamou de melhores práticas.

REST é um dos termos mais abusados hoje em dia e é realmente impossível saber a que exatente as pessoas estão se referindo quando o usam.

Muita dessa confusão vem justamente, na minha opinião, do fato de REST ser um estilo arquitetural. REST não é um protocolo, não tem "melhores práticas" (aliás, eu realmente não gosto desse termo mas essa fica pra uma outra thread :) ). REST não tem uma implementação de referência. O que REST possui é um conjunto de "constraints". O melhor lugar pra ler sobre essas constraints, imo, é na própria dissertação: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

A propósito, se você quiser continuar o exercício de modelagem, é só definir os requisitos em torno dos diferentes camcelamentos das atividades que continuamos.

Abraços,

Pedro

[CleitonMarx]

Cássio,

Achei bem válida o approach do Mário. Quando vc cancela uma atividade vc está apenas mudando o estado da atividade. Já vi muito modelo de API em que foi usado uma "action" referente a um recurso. Manda um post com a ação que vc deseja em cima de um recurso e seja feliz :)

Att.,

Cleiton Marques

>>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
>>> Para sair do grupo envie uma mensagem para dotnetarchitects+unsubscribe@googlegroups.com

>>> Para mais opções visite o grupo emhttp://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> --
> Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.

> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
> Para sair do grupo envie uma mensagem para dotnetarchitects+unsubscribe@googlegroups.com

[Sidney Lima Filho]

Nossa depois de um periodo longo, a discussão movimentou.

Eu acho que o Mario "quase" acertou em cheio. O fato de enviar uma "action" no corpo da requisição não quebra as constraints de REST, muito pelo contrário continua tratando recurso como endereçável num interface unica.

O "quase" fica na parte de "as vezes nós queremos mesmo fazer uma remote procedure call". 

Quando temos uma API REST sempre surge uma vontade que vem lá do umbigo de mandar o servidor executar alguma regra de negócio. Isso vem desde nosso aprendizado em programação onde aprendermos a dar ordens ao computador, faça isso, execute aquilo, me dá esse dado, mostre tudo isso na tela, pronto aprendemos a programar. 

Com REST não é bem assim, há um artigo bem legal do próprio Roy Fielding que cita as vezes ao construir uma API REST mas com pensamento em RPC orientado a dados, acaba criando o famoso vou colocar GET /Atividades, porque se botar  BuscarAtividades vão me trollar. :-)

Neste mesmo artigo ele cita que misturar REST com RPC, você acaba ficando com o pior dos dois, ao invés do melhor dos dois. Aumenta a complexidade, sem querer joga a gerencia de estado para o servidor, há uma tendencia em perder o acoplamento gradativamente (e quando isso acontece IMHO é o que chamamos de código que apodrece com o tempo)

Se não consegue modelar sua aplicação para uma arquitetura REST então vai de RPC e seja feliz.

Misturar padrões é o melhor caminho para não ter nenhum.

[Mário Meyrelles]

Olá Sidney,

Eu acho que concordo e entendi o que você falou. 

Por exemplo, eu nunca faria transações distribuídas utilizando REST - em caso de necessidade deste tipo, eu continuaria com opções mais "antigas", que em .NET poderiam ser serviços normais do WCF. Em REST eu faria aplicações mais simples, estilo web 2.0, para internet aberta, celulares, etc..

Estou correto? O que você faria hoje com RPC e o que você faria hoje com REST? 

Sds,

Mário

2012/5/8 Sidney Lima Filho <sidney...@perto.vc>

Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com

[Pedro Reys]

O que o wcf te dá, pra fazer transações distribuídas, que REST não proporciona?

Sent from my iPhone

[Gustavo Cruz]

tenho medo de wcf......

2012/5/9 Pedro Reys <pedr...@gmail.com>

[Mário Meyrelles]

Ele só te dá muito mais facilidade. 

2012/5/9 Pedro Reys <pedr...@gmail.com>

[Pedro Reys]

Oi Mario,

Voce pode dar exemplos dessas facilidades?

E, antes que surja outro mal entendido, meu objetivo com a perguntar eh, de verdade, entender as vantangens que voce ve que o wcf te da. Eu, pessoalmente, nao vejo muitas, mas nao duvido que existam. Por isso a pergunta.

A proposito, para transacoes distribuidas eu, a principio, nao utilizaria nem rest nem wcf. O que me vem primeiro a cabeca eh utilizar um ESB, como o NServiceBus.

- Pedro Reys

2012/5/10 Mário Meyrelles <mariome...@gmail.com>

[Sidney Lima Filho]

Pessoal, acho que agora fiquei um pouco perdido, Vê se concordam comigo.

WCF é Windows Communication Foundation correto? Uma tecnologia parte de um framework (.NET) criada por uma empresa chamada Microsoft, ou seja, um produto.

REST é Representational State Transfer correto? Uma arquitetura para sistemas distribuidos projetados para inicialmente para um protocolo HTTP.

Posso usar WCF como tecnologia para projetar uma arquitetura REST.

Posso usar WCF como tecnologia para projetar qualquer padrão de arquitetura como RPC, CEP, Message Queue, ou nenhum padrão.

Posso projetar uma arquitetura REST com qualquer tecnologia que me permita enviar e receber estados.

Agora usando a premissa acima vou te responder Mario.

O fato de fazer "transações" distribuidas não tem haver com o REST ou RPC, pois tanto um quanto outro são arquiteturas de comunicação distribuidas, a transação acontece dentro de alguma camada de abstração.

Vamos pensar numa aplicação de Banco apenas para ilustrar.

Se você modela que as camadas servidoras da aplicação irão gerenciar o estado da sua aplicação e também fornecerá regras de negócio para o cliente, então você modelou baseado em RPC.

EX: POST /Contas/00324-1/realizarSaque  {valor:1000.00}

Se você modela que as camadas servidores não gerenciam o estado de sua aplicação e uma transação é idempotente, você modelou sua aplicação baseado em REST

EX: POST /Contas/00324-1/  {valor:1000.00, acao:"realizarSaque"}

Note que o ponto não é somente tirar um "VERBO" da URL e enfiar dentro do corpo de uma requisição, mas tem todo o componente comportamental envolvido.

EX: Num ambiente Cloud, onde você não sabe em qual servidor o usuário se conecta, se um servidor cai o usuário pode continuar operar o sistema? Se sim, então atende uma das restrições que o REST impõe. Não adianta tirar o verbo da URL e usar "Session" no servidor, consegue entender?

O ESB que o Pedro citou é uma outra arquitetura de sistema distribuidos, baseados basicamente num camada de abstração assincrona que processa o envio para muitos interlocutores ao mesmo tempo. ESB está para as arquiteturas assim como um padrão Adapter está para os padrões de projeto. O problema de comunicação que um ESB resolve envolvendo camadas de uma aplicação, O padrão Adapter resolve os mesmos problemas de comunicação entre objetos de uma aplicação.

A questão entre usar REST ou RPC, de acordo com os cenários é bastante abrangente, acho que isso dá um belo post. :)

Fui claro?

[Mário Meyrelles]

Olá Sidney,

Entendi perfeitamente o que você quis dizer agora e obrigado por tomar seu tempo me respondendo.

A sua última afirmação, sobre qual estilo arquitetural utilizar em diferentes cenários, eu estava pensando aqui e realmente, dá até uma sequência de posts rs. Vou olhar com mais calma o que andam fazendo. As opções que a MS oferece são várias para diferentes cenários. Porém, eu posso dizer que gostei muito do ASP.NET Web API e estou propenso a evitar o uso e as chatices de configuração de WCF para cenários simples, como sites, chamadas ajax, aplicações mobile e mesmo, e-commerces. 

Sds,

Mário

2012/5/11 Sidney Lima Filho <sidney...@perto.vc>

Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com

[Renato Cantarino]

Prezados,

acho que pode ajudar ->  http://www.infoq.com/minibooks/emag-03-2010-rest 

--

Att,

Renato Cantarino