Estava fazendo alguns testes aqui usando a especificação Jax-RS, foi quando cheguei no verbo Delete do HTTP, então ocorreu a dúvida:
Sei que quando utilizo o Delete, ele excluirá o recurso que passei a ele como alvo (ex: DELETE /livro/1), então esta exclusão e apenas na minha camada rest(camada de saída,se é que posso chamar assim) ou isso se propaga para a minha base de dados?(Ex: eu tenho o livro com id = 1 no meu banco de dados), se alguém puder me ajudar, desde já agradeço.
[quote=@Alergictoeng]Estava fazendo alguns testes aqui usando a especificação Jax-RS, foi quando cheguei no verbo Delete do HTTP, então ocorreu a dúvida:
Sei que quando utilizo o Delete, ele excluirá o recurso que passei a ele como alvo (ex: DELETE /livro/1), então esta exclusão e apenas na minha camada rest(camada de saída,se é que posso chamar assim) ou isso se propaga para a minha base de dados?(Ex: eu tenho o livro com id = 1 no meu banco de dados), se alguém puder me ajudar, desde já agradeço.[/quote]
Tem que propagar para seu DB, nesse caso, você tem que escrever o delete do banco usando o ID recebido.
[quote=Hebert Coelho][quote=@Alergictoeng]Estava fazendo alguns testes aqui usando a especificação Jax-RS, foi quando cheguei no verbo Delete do HTTP, então ocorreu a dúvida:
Sei que quando utilizo o Delete, ele excluirá o recurso que passei a ele como alvo (ex: DELETE /livro/1), então esta exclusão e apenas na minha camada rest(camada de saída,se é que posso chamar assim) ou isso se propaga para a minha base de dados?(Ex: eu tenho o livro com id = 1 no meu banco de dados), se alguém puder me ajudar, desde já agradeço.[/quote]
Tem que propagar para seu DB, nesse caso, você tem que escrever o delete do banco usando o ID recebido. [/quote]
Huuuuuuum, entendi! mas isso não é perigoso já que meu delete é publico? ou existe uma maneira efetiva de proteger o uso destes verbos na minha api?
Bom, as vezes a deleção não precisa ser física, mas lógica.
Basta você atualizar uma flag chamada status, por exemplo, para ‘D’ ou ‘DISABLE’ ou ‘DELETED’.
No mais, basta você ter controle de acessos e um sistema de autenticação, assim o seu delete não fica público.
[quote=Rafael Guerreiro]Bom, as vezes a deleção não precisa ser física, mas lógica.
Basta você atualizar uma flag chamada status, por exemplo, para ‘D’ ou ‘DISABLE’ ou ‘DELETED’.
No mais, basta você ter controle de acessos e um sistema de autenticação, assim o seu delete não fica público.[/quote]
Mais ultilizar uma um queryParam na uri, isso não quebra o princípio “Uniform Interface”?
por exemplo: DELETE /livro/1?delete=false ( Se delete for true ele apaga se for false ele desativa.)
Não te entendi direito. Não precisa passar aquele “?delete=true”
Desculpa e que eu tinha colocado poucas informações =) mas seria assim:
por exemplo: DELETE /livro/1?delete=false ( Se delete for true ele apaga se for false ele desativa.)
Isso não quebra o princípio da interface uniforme?
Na verdade a proposta é nunca deletar de fato. Apenas desativar. Ou seja, não exsite a opção de realmente remover o registro.
Mas isso é apenas uma parte, a outra parte é o controle de acessos junto com autenticação.
Desculpa e que eu tinha colocado poucas informações =) mas seria assim:
por exemplo: DELETE /livro/1?delete=false ( Se delete for true ele apaga se for false ele desativa.)
Isso não quebra o princípio da interface uniforme?[/quote]Até hoje, ñ li nenhum livro que falava sobre "interface uniforme". Até pesquisei aqui no google para tentar entender isso.
O q eu achei foi:
Pelo que eu entendi, um recurso deve responder/tratar os métodos HTTP.
Um método delete, q realmente faz o necessário
DELETE /livro/1
É diferente de:
DELETE /livro/1?delete=false <----- Isso aqui para mim ñ faz sentido.
Existem alguns conceitos que não sei se estão claros para você:
1 - sempre proteja seu projeto. Se o DELETE não é para ser chamado por qualquer pessoa, faça com que somente um request autenticado possa chamar o delete, por exemplo, um usuário válido
2 - se necessário, crie o conceito de autorização. Se não for qualquer pessoa que possa excluir, valide se além de autenticado a pessoa tem autorização para isso, por exemplo, administrador
3 - defina qual seria o melhor excluir para você. Já trabalhei em projeto que o delete realmente chamava um delete from… e já trabalhei em projetos onde o conceito era update… set visible = false. O que você quer que seu delete faça? As vezes não faz sentido em manter algum registro na base para um projeto, mas para outro sim.
Agora se seu projeto é misto, pode ou não excluir algo do DB, aí você tem que criar algo como no seu exemplo lá em cima.
Desculpa e que eu tinha colocado poucas informações =) mas seria assim:
por exemplo: DELETE /livro/1?delete=false ( Se delete for true ele apaga se for false ele desativa.)
Isso não quebra o princípio da interface uniforme?[/quote]Até hoje, ñ li nenhum livro que falava sobre "interface uniforme". Até pesquisei aqui no google para tentar entender isso.
O q eu achei foi:
Pelo que eu entendi, um recurso deve responder/tratar os métodos HTTP.
Um método delete, q realmente faz o necessário
DELETE /livro/1
É diferente de:
DELETE /livro/1?delete=false <----- Isso aqui para mim ñ faz sentido.
Existem alguns conceitos que não sei se estão claros para você:
1 - sempre proteja seu projeto. Se o DELETE não é para ser chamado por qualquer pessoa, faça com que somente um request autenticado possa chamar o delete, por exemplo, um usuário válido
2 - se necessário, crie o conceito de autorização. Se não for qualquer pessoa que possa excluir, valide se além de autenticado a pessoa tem autorização para isso, por exemplo, administrador
3 - defina qual seria o melhor excluir para você. Já trabalhei em projeto que o delete realmente chamava um delete from… e já trabalhei em projetos onde o conceito era update… set visible = false. O que você quer que seu delete faça? As vezes não faz sentido em manter algum registro na base para um projeto, mas para outro sim.
Agora se seu projeto é misto, pode ou não excluir algo do DB, aí você tem que criar algo como no seu exemplo lá em cima.
[/quote]
Primeiro agradeço pelas respostas, conseguiram responder a minha dúvida =), mas algumas considerações sobre “o por que” da minha pergunta:
Eu estou lendo o livro RESTful-Java-JAX-RS (http://www.amazon.com.br/RESTful-Java-JAX-RS-Bill-Burke/dp/144936134X), e na página 24 (Chapter 2: Designing RESTful Services), ele fala o seguinte:
“Cancelling an Order is very similar to removing it. Since we are already modeling remove
with the HTTP DELETE method, one thing we could do is add an extra query parameter
to the request:
DELETE /orders/233?cancel=true
Here, the cancel query parameter would tell our service that we don?t really want to
remove the Order, but cancel it. In other words, we are overloading the meaning
DELETE.
While I?m not going to tell you not to do this, I will tell you that you shouldn?t do it.
It is not good RESTful design. In this case, you are changing the meaning of the uniform
interface. Using a query parameter in this way is actually creating a mini-RPC mechanism.
HTTP specifically states that DELETE is used to delete a resource from the server,
not cancel it.”
Ele salienta que não é uma boa prática, mas como em alguns casos a literatura é diferente da realidade essa foi uma pergunta pra validar se na prática as coisas realmente são assim.
já em relação a interface uniforme página 7 (Chapter 1: Introduction to REST) ele usa este termo, e como eu sou novo em rest acabei adotando por não conhecer outro.
“The Uniform, Constrained Interface
The REST principle of a constrained interface is perhaps the hardest pill for an experienced
CORBA or SOAP developer to swallow. The idea behind it is that you stick to
the finite set of operations of the application protocol you?re distributing your services
upon. This means that you don?t have an ?action? parameter in your URI and use only
the methods of HTTP for your web services. HTTP has a small, fixed set of operational
methods.”
De qualquer forma muito obrigado Rafael Guerreiro e Hebert Coelho pela atenção.
Mas quanto a estória de interface uniforme, é mais um “sentimento” que um termo HAHAHAHAH
[quote=@Alergictoeng]já em relação a interface uniforme página 7 (Chapter 1: Introduction to REST) ele usa este termo, e como eu sou novo em rest acabei adotando por não conhecer outro.
“The Uniform, Constrained Interface
The REST principle of a constrained interface is perhaps the hardest pill for an experienced
CORBA or SOAP developer to swallow. The idea behind it is that you stick to
the finite set of operations of the application protocol you?re distributing your services
upon. This means that you don?t have an ?action? parameter in your URI and use only
the methods of HTTP for your web services. HTTP has a small, fixed set of operational
methods.”
De qualquer forma muito obrigado Rafael Guerreiro e Hebert Coelho pela atenção.
[/quote]Chefe, só uma observação.
Quando eu disse que eu ñ conhecia o termo, eu ñ estava criticando blz?
Você está mais do que certo em usar termos estudados. Foi até por isso que eu corri atrás para pesquisar no google, para eu ficar menos burro no assunto. (:
Ainda bem que o q eu disse sobre o DELETE /livro/1?delete=false estava de acordo com o livro, ñ to tão longe da realidade assim! (:
[quote=Hebert Coelho][quote=@Alergictoeng]já em relação a interface uniforme página 7 (Chapter 1: Introduction to REST) ele usa este termo, e como eu sou novo em rest acabei adotando por não conhecer outro.
“The Uniform, Constrained Interface
The REST principle of a constrained interface is perhaps the hardest pill for an experienced
CORBA or SOAP developer to swallow. The idea behind it is that you stick to
the finite set of operations of the application protocol you?re distributing your services
upon. This means that you don?t have an ?action? parameter in your URI and use only
the methods of HTTP for your web services. HTTP has a small, fixed set of operational
methods.”
De qualquer forma muito obrigado Rafael Guerreiro e Hebert Coelho pela atenção.
[/quote]Chefe, só uma observação.
Quando eu disse que eu ñ conhecia o termo, eu ñ estava criticando blz?
Você está mais do que certo em usar termos estudados. Foi até por isso que eu corri atrás para pesquisar no google, para eu ficar menos burro no assunto. (:
Ainda bem que o q eu disse sobre o DELETE /livro/1?delete=false estava de acordo com o livro, ñ to tão longe da realidade assim! (:[/quote]
Quem me dera se todas as críticas fossem construtivas iguais a estas HAHAHAHAHAHAH. mais uma vez obrigado =)
[quote]"Cancelling an Order is very similar to removing it. Since we are already modeling remove
with the HTTP DELETE method, one thing we could do is add an extra query parameter
to the request:
DELETE /orders/233?cancel=true
Here, the cancel query parameter would tell our service that we don?t really want to
remove the Order, but cancel it. In other words, we are overloading the meaning
DELETE.
While I?m not going to tell you not to do this, I will tell you that you shouldn?t do it.
It is not good RESTful design. In this case, you are changing the meaning of the uniform
interface. Using a query parameter in this way is actually creating a mini-RPC mechanism.
HTTP specifically states that DELETE is used to delete a resource from the server,
not cancel it."
Ele salienta que não é uma boa prática, mas como em alguns casos a literatura é diferente da realidade essa foi uma pergunta pra validar se na prática as coisas realmente são assim. [/quote]
Você pode usar o mesmo método mas criar outro resource, por exemplo:
DELETE orders/233 <- cancela
DELETE canceledOrders/233 <- remove
Assim não viola a interface uniforme, nem compromete a idempotencia do método delete.
[quote=pfk66][quote]"Cancelling an Order is very similar to removing it. Since we are already modeling remove
with the HTTP DELETE method, one thing we could do is add an extra query parameter
to the request:
DELETE /orders/233?cancel=true
Here, the cancel query parameter would tell our service that we don?t really want to
remove the Order, but cancel it. In other words, we are overloading the meaning
DELETE.
While I?m not going to tell you not to do this, I will tell you that you shouldn?t do it.
It is not good RESTful design. In this case, you are changing the meaning of the uniform
interface. Using a query parameter in this way is actually creating a mini-RPC mechanism.
HTTP specifically states that DELETE is used to delete a resource from the server,
not cancel it."
Ele salienta que não é uma boa prática, mas como em alguns casos a literatura é diferente da realidade essa foi uma pergunta pra validar se na prática as coisas realmente são assim. [/quote]
Você pode usar o mesmo método mas criar outro resource, por exemplo:
DELETE orders/233 <- cancela
DELETE canceledOrders/233 <- remove
Assim não viola a interface uniforme, nem compromete a idempotencia do método delete.[/quote]
Faz total sentido =) valeu pfk66