[php-brasilia] restfull registro não encontrato

[Felipe Moura]

Bom dia pessoal,

Desenvolvendo uma webservice restfull tive uma dúvida e queria saber a opinião de vcs. Em caso de registro não encontrado qual code status deve ser retornado? 404? 204? outro?

Abraço!

--

Atenciosamente,

Felipe Moura
Desenvolvedor Web
http://about.me/felipewebdf 
twitter: @felipewebdf
talk: felip...@gmail.com
msn: gu...@hotmail.com

(61) 8490-8156

[Luís Otávio]

404

2013/1/16 Felipe Moura <felip...@gmail.com>

[Daniel Ribeiro Gomes]

Eu diria um 204, de acordo com as especificações do protocolo:http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

As requisições completadas com sucesso começam com 2, e as completadas sem sucesso, com 4.

Neste caso, a requisição seria completada com sucesso, e retornaria um 204 - No Content.

Daniel Ribeiro Gomes Pereira

Twitter | Facebook | LinkedIn

iPhone: +55 (48) 9111-0931

[Daniel Ribeiro Gomes]

OBS.: Acho que a sugestão do Luís, o 404, seria apropriado também.

Daniel Ribeiro Gomes Pereira

Twitter | Facebook | LinkedIn

iPhone: +55 (48) 9111-0931

[Luís Otávio]

"The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. "

Tradução por cima: "o servidor completou a requisição mas não precisa do retorno do conteúdo".

Não necessitar da transferência do conteúdo é diferente de não encontrar o recurso, dessa forma o retorno mais apropriado é o 404 Not Found, visto que o recurso não foi encontrado (The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.).

2013/1/16 Daniel Ribeiro Gomes <drgo...@gmail.com>

[Daniel Ribeiro Gomes]

Concordo.

404 é o apropriado neste caso.

Sempre me gerou dúvida esses dois, hehehe 

Valeu Luís

Daniel Ribeiro Gomes Pereira

Twitter | Facebook | LinkedIn

iPhone: +55 (48) 9111-0931

[Arthur Cláudio Almeida Pereira]

Ou eu ou o Luís lemos errado pois o texto que ele "copiou" na mensagem antiga era relativo ao código 204 e não ao 404. 
Acho que deveria ser o 204 mesmo. 

abraços

[Luís Otávio]

A primeira parte copiada é do 204 "The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation." a segunda é do 404 "The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent."

2013/1/16 Arthur Cláudio Almeida Pereira <arthur.alm...@gmail.com>

[Arthur Cláudio Almeida Pereira]

Desculpe, não tinha entendido anteriormente.

Mas vamos lá, o recurso foi encontrado mas não existe nada para retornar dele.  No caso ainda acha mais apropriado o 404? 

[Daniel Ribeiro Gomes]

Não, Arthur, eu que me equivoquei na interpretação do 204.

O correto é o 404 mesmo.

Daniel Ribeiro Gomes Pereira

Twitter | Facebook | LinkedIn

iPhone: +55 (48) 9111-0931

Em 16 de janeiro de 2013 11:11, Luís Otávio <lcob...@gmail.com> escreveu:

[Luís Otávio]

A pergunta do Felipe foi:

"Desenvolvendo uma webservice restfull tive uma dúvida e queria saber a opinião de vcs. Em caso de registro não encontrado qual code status deve ser retornado? 404? 204? outro?"

Ou seja, a parada NÃO FOI ENCONTRADA =D

[Arthur Cláudio Almeida Pereira]

Ah blz..
Tinha entendido que o recurso tinha sido encontrado mas ele não tinha nada para retornar ao invés do recurso em si não ter sido encontrado! valeu!!! =D

[Felipe Moura]

Pessoal, o recurso foi encontrado, o que não foi encontrado foram os registros... 

Lancei essa dúvida porque buscando na net vi as duas interpretações, e achei legal discutir o assunto. Em todo caso optamos pelo 204, pois como o Arthur mencionou o recurso foi encontrado apenas os dados solicitados é que não foram encontrados, ou seja, não vejo um erro nessa hora e os status code começando com 4 se referem a erros. Enfim, é confuso.

Apenas para constar, fiz essa opção não acho que seja a verdade absoluta, pois muitos artigos falam em utilizar o 404, a dúvida ainda persiste.

[Felipe Moura]

Queria levantar uma questão que talvez de uma luz, o recurso é a url + parametros, ou so a url?

Porque se um recurso for url+parametro então o 404 seria o mais indicado, caso ao contrário o 204 parece ser mais apropriado.

O que vcs acham?

[Silvano Girardi Jr]

O RFC fala de Request-URI.

http://ftp.ics.uci.edu/pub/ietf/http/rfc1945.html#Request-URI

Request-URI    = absoluteURI | abs_path

http://ftp.ics.uci.edu/pub/ietf/http/rfc1945.html#URI

abs_path = "parametros" passados para a URL

Abraço,

Silvano

2013/1/16 Felipe Moura <felip...@gmail.com>

[Felipe Moura]

Boa Silvano, dessa forma acredito que o 404 seja o correto mesmo, aproveitar e dar uma boa lida no RFC novamente que deixei passar essa.

Vlw

[Walker de Alencar]

Depende da estrutura de retorno que vc definir.

Se vc definir estruturas com detalhamentos é possível trabalhar isso de forma mais adequada.

Eu costumo usar saídas em json com a seguinte estrutura:

{

  info: {

    application: {

      name: 'sppName',

      version: 'x.y.z'

    },

    status: {

      result: true|false

      text: 'mensagem amigavel de retorno'

    },

    messages: [{code: xxx, text: 'Ispum', type: ''}], //havendo erros pode-se listar cada um deles, e detalhar

    created: 'yyyy-mm-dd hh:mm:ss',  

    ttl: 'yyyy-mm-dd hh:mm:ss', //até quando será válido, TTL = Time To Live

  },

  content: objContent  // vai depender do conteúdo que vai retornar.

}

Antes de perguntar: pq isso tudo eu explico.

Partindo do contexto que um webservice rest atua no protocolo HTTP, qualquer retorno diferente de 200, deve ser tratada como tal.

Qualquer informação que o servidor processou e deu algum tipo de retorno deve ser sempre, sem exceção:  código 200. Contendo detalhes de cada operação, ou seja, nome e versao da aplicação em questao, data que foi criado o conteúdo, es o conteúdo for cached tem como identificar a idade desse conteúdo, bem como o prazo de validade dessa informação.

No caso do status, vc consegue saber se tudo ocorreu bem, pelo status code e trazer uma mensagem genérica para apresentar ao usuário.

Havendo erros, ou processamentos em lotes, vc pode usar a parte de messages, para exibir quantas forem necessárias identificando: codigo, mensagem detalhada e tipo da mensagem.

E finalmente a estrutura de conteúdo, que em casos de falhas pode ser omitida.

Dessa forma, você consegue ter um nível de controle melhor client-side e facilita os debugs.

No Caso do RESTful, pelas normas, deve-se fazer alguns ajustes de retorno do status code do response, mas é possível manter a mesma estrutura, melhorando a "verbosidade" do serviço.

Sussa;

--

Walker de Alencar
Arquiteto de Sistemas PHP
http://www.walkeralencar.com
(61) 8599-8999 | (62) 8172-5487
ZCE: ZEND014591

[Silvano Girardi Jr]

Eu particularmente prefiro uma arquitetura como esta do Walker. Não acho interessante utilizar status code do servidor web como sendo os status code da minha aplicação.

Seu servidor web pode vir a ter algum problema, mesmo que temporário, e retornar 404 porque de fato não conseguiu encontrar os arquivos no servidor. Porém a aplicação consumindo o serviço não vai saber diferenciar isso de uma requisição em que um registro não foi encontrado. Isto pode causar problemas difíceis de serem debugados.

Silvano

2013/1/16 Walker de Alencar <walker...@gmail.com>

[caferrari]

Se o servidor tem algum problema, ele não vai retornar 404.. a conexão simplesmente não vai acontecer ou vai dar um timeout.

Caso você precise atualizar algo no servidor (mudar arquivos de lugar por exemplo) você pode simplesmente fazer ele retornar o codigo 503 até que tudo esteja ok, assim evitando 404 indesejados

Vocês estão querendo criar mais uma camada acima do HTTP para fazer exatamente o que ele foi feito para fazer.


[]'s

--
Carlos André Ferrari
http://ferrari.eti.br
http://github.com/caferrari
http://meadiciona.com/caferrari
OpenPGP keys: 113D04FC

[Eder Freire]

Eu também não utilizo, nos sistemas que desenvolvo também faço a mesma coisa que o Walker faz, muito mais fácil deixar tudo explicito!

Em 16 de janeiro de 2013 14:27, Silvano Girardi Jr <silv...@gmail.com> escreveu:

--
Sem mais,

Eder Freire
Analista Programador
ederss...@gmail.com

[Felipe Moura]

Entendo e acho lega este tipo de abordagem, mas isso ja temos no soap. Em restfull qual seria o sentido de fazer todo esse encapsulamento dos dados visto que o http ja os tem?

[Silvano Girardi Jr]

O servidor pode perfeitamente retornar 404 se houver um problema com a montagem da partição onde estão os arquivos web, por exemplo. Existem outras razões também pela qual isso pode acontecer, como o desenvolvedor apagar o arquivo sem querer, disco corromper, etc. etc. etc.

Silvano

2013/1/16 caferrari <cafe...@gmail.com>

[Silvano Girardi Jr]

O sentido está em poder diferenciar o que é erro de aplicação e o que é erro do servidor web.

2013/1/16 Felipe Moura <felip...@gmail.com>

[Luís Otávio]

"10.4 Client Error 4xx

The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents SHOULD display any included entity to the user.

If the client is sending data, a server implementation using TCP SHOULD be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes the input connection. If the client continues sending data to the server after the close, the server's TCP stack will send a reset packet to the client, which may erase the client's unacknowledged input buffers before they can be read and interpreted by the HTTP application."

Quando o erro for da aplicação, o body do response deverá indicar isso.

2013/1/16 Silvano Girardi Jr <silv...@gmail.com>

[Felipe Moura]

Bem, se o erro for de servidor não vai haver retorno, ou seja, esse encapsulamento de nada serviria, não?

Outra questão é que levando em consideração que restfull utiliza a interface do protocolo HTTP, vcs não acham que fazendo esse encapsulamento deixa de ser restfull? A aplicação cliente não poderá se basear no protocolo e sim no retorno.

[Eder Freire]

Exato... Mas ai sei que o erro é de servidor e não de aplicação!

Em 16 de janeiro de 2013 14:58, Felipe Moura <felip...@gmail.com> escreveu:

Outra questão é que levando em consideração que restfull utiliza a interface do protocolo HTTP, vcs não acham que fazendo esse encapsulamento deixa de ser restfull? A aplicação cliente não poderá se basear no protocolo e sim no retorno.

[Silvano Girardi Jr]

Respostas no corpo da mensagem:

2013/1/16 Felipe Moura <felip...@gmail.com>

Bem, se o erro for de servidor não vai haver retorno, ou seja, esse encapsulamento de nada serviria, não?

Serve. Se não houver retorno eu sei que o problema é no servidor.

 

Outra questão é que levando em consideração que restfull utiliza a interface do protocolo HTTP, vcs não acham que fazendo esse encapsulamento deixa de ser restfull? A aplicação cliente não poderá se basear no protocolo e sim no retorno.

Uma aplicação pode ser chamada RESTful se ela está em conformidade com os princípios (constraints) de REST: http://en.wikipedia.org/wiki/Representational_state_transfer#Constraints

"The REST architectural style describes the following six constraints applied to the architecture, while leaving the implementation of the individual components free to design."

Enquanto existe uma definição dos métodos HTTP para serem utilizados (GET, POST, etc.), não existe uma definição sobre a utilização dos status codes.

Silvano

[Wesley Victhor Mendes]

É triste ver respostas como a do Walker e muitos outros concordando com tal.
Concordar com esse comentário é concordar em quebrar a web. Quebrar o
que algumas pessoas pensaram da
melhor maneira a anos atrás...

A abordagem do Walker é o que o flash trouxe para a web, com sua
limitação de acesso aos code status do protocolo aplicações começaram
a retornar mensagens e status no corpo do documento e o response
sempre 200. oohh shit. why...

Os status codes estão lá, classificados e definidos para serem
utilizados, o problema é: saber como.

A classificação dos status code tem um sentido e imagino que os
presentes nessa thread viu na especificação:
1** informacional
2** sucesso
3** redirecionamentos
4** erro no cliente
5** erro no servidor

Seguindo essa classificação vamos pensar na dúvida do nosso amigo que
abriu a thread.

Uma vez que existe um problema ou um erro de recurso quem foi o
responsável por digitar o recurso normalmente é o client(usuário) o
que nos leva a categoria 4**. Uma outra pergunta a ser feita é: esse
recurso existe ? Se sim o code status 404 ja não faz mais parte do
nosso problema. Uma outra pergunta é: esse recurso está sendo
requisitado da maneira correta(parametros, headers, método) ? Se sim,
o code status 400 ja não faz mais parte do nosso problema. Agora,
existe o recurso e tudo está correto, mas eu não tenho a representação
do meu recurso para ser exibida logo, temos um 204. A especificação
deixa clara o uso do 204 em sua própria mensagem "No Content". Sabemos
que a requisição chegou com sucesso, sabemos que não existe um
conteúdo, 204.

Agora, qual a importancia do status code ? Por que é errado uma
aplicação sempre retornar 200 ?
O status code é como se fosse uma chave de classificação em uma
conversa, pense que para cada chave um assunto é tratado. uma vez que
sua aplicação só retorna 200, motores de busca e outros softwares que
podem utilizar sua aplicação não saberão qual linguagem você está
falando, a não ser que o seu conteúdo(corpo) me explique, o que faz
outras aplicações necessitarem de workarounds.

Ja perceberam como o browser se comporta quando ele recebe um response 204 ?
Ele simplesmente não faz nada, não recarrega a pagina, não atualiza o
recurso, ele fica com a representação anterior, por que isso ? Porque
não existe conteúdo, se não existe conteúdo não existe o que
apresentar.


2013/1/16 Eder Freire <ederss...@gmail.com>:

[Silvano Girardi Jr]

Não fique triste Wesley. Enxugue as lágrimas e leia com um pouquinho mais de atenção o que o Walker escreveu.

Silvano

2013/1/16 Wesley Victhor Mendes <w.v.me...@gmail.com>

[Wesley Victhor Mendes]

hehe, valeu silvano, estou mais calmo :)

2013/1/16 Silvano Girardi Jr <silv...@gmail.com>:

[Walker de Alencar]

Tente fazer requisições ajax e recuperar os dados do header do response, que vc descobrirá os problemas....

Fazer webservice rest para ser consumido por PHP é tranquilo, pq vc recupera facilmente as informações, mas informações extendidas do header, são ignoradas via ajax.

No meu caso, a maior parte do consumo é em web apps e mobile apps.

E gerencio as regras de Negocio e messages server-side, assim posso ter vários clientes diferentes utilizando o mesmo padrão de mensagens, e qualquer falha consigo debugar facilmente se o modo de debug estiver habilitado.

No caso de vc colocar todas as regras client-side, messages e afins, realmente é desnecessário colocar a estrutura que citei.

ex.: /user/walkeralencar

Se nao encontrar o usuario walkeralencar, retornar erro 404? nada haver, o servidor processou a informação, fez os procedimentos dele, e viu que nao tinha informação do usuário. 

Tenho duas opções em REST, posso retornar status code 200 e passar o detalhamento dos dados.

No caso do RESTful, se for consumir via php, pode passar um status code 204 (No Content), e as informações diretas no header do response.

Resumindo, vai muito do problema que vc quer resolver.

Sussa.

[Walker de Alencar]

Não vou comentar detalhes, para nao alimentar discussão desnecessária, como citou o Silvano, releia o texto.

Para quem já me conhece há tempos, sabe que sou um dos malucos que mais defendem padronizações aqui no brasil, apesar de atualmente estar mais na área negocial/arquitetural de sistemas e menos participativo nas comunidades em decorrencia e falta de tempo.

Mas continuemos as discussões sobre o tema que está bem interessante. :)

[Wesley Victhor Mendes]

Uma coisa é não ter informações para um usuário, outra coisa é o recurso não existir.

Com javascript eu posso criar uma estratégia para cada tipo de status code.

Consigo obter e enviar headers sem problemas...

Como o caferrari comentou, é como criar uma camada que faz a mesma coisa que o http faz.

2013/1/16 Walker de Alencar <walker...@gmail.com>

Não vou comentar detalhes, para nao alimentar discussão desnecessária, como citou o Silvano, releia o texto.

[Walker de Alencar]

Wesley, na boa.

Realmente nao entendi onde foi que entrou a "camada que faz a mesma coisa que o http" nas coisas que citei.

No meu caso eu tenho que fazer dessa forma, para manter quase 40 aplicações conversando com as que lhe convir, cada uma responsável por sua respectiva regra de negócio e messages. Se eu tiver que tratar mensagens por status code dentro de 39 aplicações que consomem os serviços do módulo financeiro, seja esse consumo em java, php, delphi ou js. Como se espera padronizar as mudanças de mensagens para cada uma delas quando houver mudanças no server em decorrencia de um ajuste de nível de negócio? Mesmo que eu crie componentes por linguagem, ainda assim seria inviável manter.

Nas citações que fiz separei REST de RESTful.

Portanto, sou totalmente aberto a expandir meus conhecimentos e tentar realmente entender o contexto e o conceito que vc está abordando. Pois se houver algo que eu possa melhorar no que tenho atualmente, com certeza buscarei isso.

Att.

[Eder Freire]

Concordo com Walker.

Eu tenho esse mesmo cenário aqui, e a solução que adotamos, para solucionar isto, foi exatamente a mesma Walker, a diferença aqui é apenas as linguagens que utilizamos!

[Wesley Victhor Mendes]

Entendo perfeitamente sua situação.(embora não tenha entendido nada do seu último comentário. rs.)

Apenas quis colocar que é possível ter uma aplicação trabalhando totalmente em cima do protocolo HTTP.

Ela é minha camada de aplicação, ela ja abstrai tudo isso.

2013/1/16 Eder Freire <ederss...@gmail.com>

[Luís Otávio]

Vou usar o exemplo do Walker pra expressar minha opinião, e que vai ao encontro do que o Wesley tá falando:

GET /user/walkeralencar

O recurso é /user/walkeralencar e o cliente está querendo uma representação do estado dele.

Se o recurso não existir no servidor o status deve ser 404, pois para o cliente, não interessa se essa resposta veio do serviço web ou da aplicação rodando em cima dele, o que interessa é que este recurso não existe no servidor. É um erro 4xx porque o cliente acessou um recurso inexistente.

O status 204 se aplicaria quando está se filtrando uma coleção e não existe nenhum resultado com os parâmetros buscados, ou seja:

GET /users?name=Walker%20Alencar

O recurso /users existe, porém após a aplicação dos filtros nenhum dado é encontrado, ou seja No Content. Neste caso também é possível usar o status 200 é um "[]" caso o header Accept tenha sido application/json.

Importante ressaltar que (até onde conheço) RESTful é o software que segue o estilo REST, portanto não dá pra separar REST de RESTful (povo que manja de inglês pode confirmar qual é o significado do sufixo "ful").

Quanto à questão da "camada que faz a mesma coisa que o http" imagino que seja justamente o fato de ter definido um padrão para enviar os erros de processamento da aplicação e responder sempre o status code 200. Por exemplo:

Faz uma requisição GET à /user/walkeralencar e o retorno é 200 com o conteúdo:

{

  info: {

    application: {

      name: 'sppName',

      version: 'x.y.z'

    },

    status: {

      result: false,

      text: 'O usuário walkeralencar não foi encontrado'

    },

    messages: [{code: 4564, text: 'Blablabla', type: 'MothaFockaError'}],

    created: 'yyyy-mm-dd hh:mm:ss',  

    ttl: 'yyyy-mm-dd hh:mm:ss',

  },

  content: {}

}

Com esse tipo você criou um protocolo acima do protocolo HTTP, onde suas aplicações sabem o formato da mensagem pra tratar o erro. Na minha visão (e na do Wesley tb pelo que eu entendi) isso é desnecessário se você responder com status 404 e a mensagem de erro como conteúdo do response.

Att,

Luís

2013/1/16 Wesley Victhor Mendes <w.v.me...@gmail.com>

Uma coisa é não ter informações para um usuário, outra coisa é o recurso não existir.

[Luís Otávio]

Só uma correção o protocolo de resposta que você falou não é só pra erro, e sim para qualquer coisa.

Isso faz com que quando uma request dê certo você não retorne a representação do estado de um recurso, mas sim essa representação encapsulada num monte de coisas (e isso de certa forma é meio estranho na minha opinião).

Att,

Luís

2013/1/16 Luís Otávio <lcob...@gmail.com>

[Wesley Victhor Mendes]

É isso ae Luís.

Walker é até curioso pensar como você lida com redirecionamentos, é o mesmo esquema ? sempre 200 ?

2013/1/16 Luís Otávio <lcob...@gmail.com>

[Felipe Moura]

Também vou na linha de que o protocolo http por si só resolve o estado da requisição, e novamente ressalto que o soap ja tem a pratica de fazer essa camada a mais e fica meio sem sentido se tratando de rest ou restful querer fazer o mesmo.

[Walker de Alencar]

no meu caso o router é: /user/:name, logo /user é o recurso, e walkeralencar seria um filtro do parametro :name; Sendo assim o correto é usaro retorno de 204.

A parte de info pode ser chamada de header tb, é retornada, para facilitar a identificação de informações, que PODEM ser passadas diretamente via HEADER do response, inibindo essa parte.

{

  header: {

    application: {

      name: 'sppName',

      version: 'x.y.z'

    },

    status: {

      result: false,

      text: 'O usuário walkeralencar não foi encontrado'

    },

    created: 'yyyy-mm-dd hh:mm:ss',

    ttl: 'yyyy-mm-dd hh:mm:ss',

  }

}

Em 16 de janeiro de 2013 16:52, Luís Otávio <lcob...@gmail.com> escreveu:

[Luís Otávio]

Aí está o problema Walker!

Você está interpretando a URI de forma incorreta.

A sintaxe geral de uma URI é: <scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ] (http://en.wikipedia.org/wiki/URI_scheme#Generic_syntax)

Parâmetro de filtro é queryString e não o path do recurso, dessa forma o recurso é /user/walkeralencar =D.

Att,

Luís

[Wesley Victhor Mendes]

Walker, não é por que na sua aplicação você denominou :name como um filtro que no final seu recurso representará um.

Recursos em sua forma mais natural (node_path) são nada mais que representações de estrurua de diretórios...

esse conceito surgiu lá atrás com o nascimento do ftp.

Logo o recurso /user/wesley define uma arvore, assim como /book/gof, etc.

Isso está mais relacionado a semântica das suas uris, ao real conceito que você está definindo a elas.

[Walker de Alencar]

Putz, vc realmente leu o que eu escrevi?

Citando que todos os retornos diferentes de 200 devem ser tratados devidamente.

O 200 foi citado para consulta de um resource, que fez todo procedimento de consulta, tratou os dados, viu q nao tinha o usuário, e respondeu OK(200), Fiz todas as verificações, você consumiu o recurso corretamente, mas o parametro de filtro que vc me deu, não há dados que o atenda. portando informe ao usuário a seguinte mensagem definida na regra de negócioo: 'xxxx', essa consulta foi criada tal hora, está em cache agora e é válida por 5minutos, ou até que alguém modifique os dados internamente e a atualize conforme sua regra de negócio, para fins de auditoria, o serviço que vc consumiu foi da aplicação XXX na versão YYY no momento dessa consulta.

No MEU caso, tive que fazer dessa forma, hora nenhuma citei que era absolutamente correta e todas as outras abordagens estavam erradas.

Como gosto sempre de citar: "Cada ponto de vista é visto de um ponto.", dependendo da sua necessidade e objetivos, o que fiz pode não se aplicar.

Att.

[Wesley Victhor Mendes]

Na verdade o que fez não era necessário, só isso. rsrs.

Com essa idéia que você traz sobre a regra de negócio em cima das mensagens, da uma sensação de que

você faz todo esse processo apenas por causa da regra de negócio, o que deveria estar em outra arquitetura... nada muito sério, just feelings. rs.

[Daniel Ribeiro Gomes]

Pontos de vista não distorcem, geralmente, a verdade.

Att.

Daniel Ribeiro Gomes Pereira

Twitter | Facebook | LinkedIn

iPhone: +55 (48) 9111-0931

[Eder Freire]

Wesley, como vc faria isso? Eu tenho o mesmo cenário que o Walker em uma aplicação, fiquei curioso.

[Wesley Victhor Mendes]

Eder. eu faria utilizando HTTP. :)

Considerando o caso do Walker.

meus recursos serião definidos sempre pensando em estruturas de diretórios.

/user/wesley/

Eu posso trabalhar apenas com o protocolo. Métodos(GET, POST, PUT, DELETE) utilizados definem ações, code status definem situações.

Exemplo simples no javascript:

$.ajax({

    url: '/user/wesley/' +'?'+ filterParams,

    statusCode: {

         200: successHandler,

         204: noContentHandler,

         404: notFoundHandler

    },

    dataType: 'json'

});

Eu posso extender a camada de code status do protocolo, por que não ?

Posso criar um status code expecífico: 242 "Usuário existe mas não ativo"

A regra de negócio deve estar na minha aplicação e não no protocolo, a minha regra de negócio pode

influenciar o meu response mas não estar contido nela.

Existem os que defendem que o MVC ja está na camada HTTP(apenas comentando não vamos entrar nessa, rs.)

Eder, é dificil falar como melhorar seu aplicação sem realmente conhece-la, imagino o universo que o Walker está rodeado e muito complicado de lidar, ja trabalhei em situações parecidas, mas a realidade é. ja vi serviços onde nada dessa arquitetura que vocês tem foi necessário.

Um exemplo simples é a Netflix, um dos serviços REST mais ful que conheço, e eles lidam com diversos dispositivos e para cada dispositivo uma regra de negócio e arquitetura diferente. Pensem na complexidade que eles teriam que lidar se o protocolo ja não abstraisse a responsabilidade da comunicação ?

E o Spotify que tem seu próprio protocolo para stream, eles brincam de HTTP. :)

Tudo soa tão simples e natural para as aplicações, é como se elas falassem o mesmo idioma.

2013/1/16 Eder Freire <ederss...@gmail.com>

[Walker de Alencar]

Para fomentar o assunto:

http://www.infoq.com/articles/designing-restful-http-apps-roth

http://blog.thefrontiergroup.com.au/2012/08/http-status-codes-and-restful-api-crafting/

http://satishgopal.wordpress.com/tag/rest-status-codes/

http://restpatterns.org/HTTP_Status_Codes

http://www.develop.com/httpstatuscodesrest

Como ainda nao se tem algo bem fechado, cada um implementa de forma diferente, mas o interessante é que há padroes entre eles que são bem similares.

Sussa.

[Walker de Alencar]

Esqueci de um que é um exemplo de uso... é java, mas o importante é a referencia de uso do REST.

http://www.linhadecodigo.com.br/artigo/2059/web-services-rest.aspx

[Daniel Ribeiro Gomes]

Precisamos lembrar o seguinte:

Não existe um padrão oficial para uma arquitetura Restful, já que é apenas um padrão arquitetural.

No caso do SOAP, estamos lidando com um protocolo, com um padrão bem definido.

Mesmo não sendo um padrão, uma arquitetura Restful deve estar implementada com base nos padrões da web.

Neste caso, a correta utilização dos statuses codes do protocolo HTTP é necessária.

Daniel Ribeiro Gomes Pereira

Twitter | Facebook | LinkedIn

iPhone: +55 (48) 9111-0931