Atualizar e Excluir sem uso da $_GET

[Andrey Knupp Vital 136]

De fato, o método DELETE não é obrigado a retornar 204.

 

Mas só para deixar claro: eu prefiro fazer isso, não estou falando que é o certo ou o errado, apenas prefiro. Eu acho que o fórum tem mais utilidade do que simplesmente ajudar com códigos prontos...

 

Não precisa dar código pronto, nem colocar pedras no caminho do cara.

[cristianoolv 93]

Для упрощения, что если мы можем усложнить?

[hinom 5]

#62 rssss

 

KISS

[Enrico Pereira 299]

Abraham Lincoln falando russo :lol:. Complicação é subjetiva e o que pode ser complicado para fulano pode ser algo simples para beltrano e vice-versa.

 

Andrey, eu concordo, às vezes eu sou xiita com péssimas práticas e fico "não use mysql_*, não use @, etc.", estarei tentando melhorar isso, senhor.

 

Henrique, o que você sugere então como alternativa?

[Bruno Augusto 417]

Eu duvido que QUALQUER pessoa, órgão, empresa siga alguma RFC complexa como a HTTP 100% risca.

 

Qual o problema de /users/delete/1? Você não viola a especificação, você são não a segue ao pé da letra. Se nem os browsers seguem, por não aceitarem os diferentes métodos, simplesmente não aceitemos também.

 

Sem contar que, do ponto de vista programático, fica mais elegante do que ter a URL amigável e estritamente à risca e um ?action=deletar no final. Ou então fazer mais uma condição só pra determinar a real intenção daquele formulário.

[Enrico Pereira 299]

Eu duvido que QUALQUER pessoa, órgão, empresa siga alguma RFC complexa como a HTTP 100% risca.

 

Ninguém segue. Há varios de facto standards no HTTP, como os headers X-*

 

Eu faço isso porque eu prefiro, simples assim, eu prefiro porque para mim faz mais sentido, não tenho nenhum argumento além deste.

 

Essa condição pode ser feita de maneira automática por algum router. O Respect\Rest possui essa feature: https://github.com/Respect/Rest#anti-patterns (É um anti-pattern para o bem).

 

---

 

Mas pessoal, vamos voltar ao tópico, mais de 60 posts por uma discussão idiota de preferência.

 

Acho super positivo "puxar a orelha" e ensinar boas práticas num tópico de dúvidas, mas 60+ posts (quase 5 páginas)? WTF estamos fazendo? O tópico, afinal, é uma dúvida ou uma discussão sobre usar POST/DELETE/Whatever?

 

---

 

Ao autor do tópico: GET e POST não mudam a segurança. A única diferença se você for usar POST é que você vai usar $_POST ao invés de $_GET para recuperar os dados.

[Evandro Oliveira 331]

Então eu proponho o seguinte.

 

Use um campo extra para indicar qual a ação será realizada:

 

 

 

<input type="hidden" name="method" value="delete">

Use JavaScript para capturar o evento de submeter o formulário e envie o formulário via XHR usando o método indicado no campo "method" e remova esse campo.

 

 

Por um tempo eu mantive um utilitário AJAX que submetia formulários usando o método descrito no formulário como método da requisição XHR.

 

Apenas pra lembrar que a melhor forma de se fazer algo é a certa, ao invés de criar um elemento escondido e removê-lo, podemos usar o elemento [inline]<button>[/inline]

<thead>
    <tr>
        <th>Nome
        <th>Idade
<tbody>
    <tr>
        <th>José da Silva
        <th>50
            <form method="post" action="">
                <input type="hidden" name="id" value="900">
                <button type="submit" name="do" value="edit">Editar</button>
                <button type="submit" name="do" value="delete">Excluir</button>

However, ainda assim ... é FRESCURA de mais e um custo benefício péssimo pra quem envia um AJAX só pra usar um 'DELETE', sendo que o resultado final será o MESMO que usando GET.

Abra um pouco a sua mente. Pense em API restful. Webservices. Se a sua implementação Javascript já for uma consumidora do seu próprio webservice, quando seu chefe chegar com essa "incrível e revolucionária" ideia, ela já estará pronta, implementada, testada e funcionando. Suporte o browser, mas faça o JavaScript operar como o curl/wget operarão. Como a implementação em outra linguagem que não a server-side que você vai utilizar operará. Como a intercomunicação entre os sistemas que você mantém operará. Se é um passo à frente sem custo, porque não implementar???

 

Discordo de você. O POST também serve para recuperar dados, quem lhe disse que não? Um exemplo prático disso é requisições AJAX, e o framework ExtJS você escolha em GET ou POST para recuperar ou sei lá tu quer fazer.

O único verbo que implica uma resposta em branco é o HEAD.

 

 

Não disse que POST /users/deletar faz sentido, estou falando sobre enviar AJAX só pra usar o verbo DELETE.

 

Eu também sou, por isso faço as coisas como EU acho que devo, não to nem ai pra opinião lá do cara do terceiro andar, pra tua opinião, pra opinião de um pica ai da informatica ... o código é meu, eu que escrevi, eu que mando, eu que deleto, eu que modifico, e ponto.

Já colaborou com projetos opensource? Já pensou/desejou ter algum código/serviço/utilitário seu disponibilizado para público?

 

Então vamos fazer workaround esdrúxulos só pra seguir a RFC.

 

No fim das contas, você continua usando GET para apagar dados.

 

 

Exato, vantagem nenhuma, só desvantagens.

 

Seguir especificações que realmente ajudam em algo é algo que todo bom desenvolvedor deve fazer, agora ficar caçando gambiarra pra "corrigir" algo desnecessário é total perda de tempo.

Impedir o método GET de alterar dados, por si só já é uma primeira proteção contra CSRF. Imagina abrir um site qualquer que contenha

<img src="http://siteatacado.com/profile/delete/confirm">

Que tal?

 

Ao autor do tópico: GET e POST não mudam a segurança. A única diferença se você for usar POST é que você vai usar $_POST ao invés de $_GET para recuperar os dados.

http://www.php.net/manual/en/reserved.variables.request.php

[mangakah 217]

Evandro,

 

de fato sua solução é melhor para formulários com múltiplas ações, quero só sugerir uma alteração: para manter a semântica, usar o elemento INPUT ao invés de BUTTON, sendo ambos com type=submit. Estes elementos e com este tipo tem comportamento idêntico, mas eles tem propriedades diferentes; BUTTON permite que se inclua elementos dentro dele, como IMG, etc., enquanto INPUT também tem o tipo "image", que permite uma imagem como botão. Semanticamente, na minha opinião, INPUT é um elemento mais apropriado para armazenar uma entrada de informação.

 

O que você acha?

[Andrey Knupp Vital 136]

Abra um pouco a sua mente. Pense em API restful. Webservices. Se a sua implementação Javascript já for uma consumidora do seu próprio webservice, quando seu chefe chegar com essa "incrível e revolucionária" ideia, ela já estará pronta, implementada, testada e funcionando. Suporte o browser, mas faça o JavaScript operar como o curl/wget operarão. Como a implementação em outra linguagem que não a server-side que você vai utilizar operará. Como a intercomunicação entre os sistemas que você mantém operará. Se é um passo à frente sem custo, porque não implementar???

 

Pow, que foda, mas eu dou solução para o problema que o cliente tem.

 

Um cara quer ali um controle financeiro, eu vou fazer API disso pra que ? é um programa que roda online, só isso, o único problema que ele quer resolver é disponibilizar seu acesso em qualquer lugar, só isso, não quer criar API nem nada disso não meu.

 

Eu até entendo o que você fala, mas caramba ... eu faço o negócio funcionar, sacou ? se tu gosta ai de fazer JS, de sei lá o que, e de ficar programando ai coisas que nem precisa e vai dar o mesmo resultado pro cliente (porém com MAIS CUSTO), ai é problema teu saka ? eu curto fazer desse jeito, NÃO é gambiarra, funciona direitinho, e nunca levei um ataque em massa que meu deus nossa senhora.

 

Eu só resolvo um problema, quando eu tenho um problema. Se tu gosta ai de ficar fazendo coisa que o cara nem vai precisar, problema seu também, ai é contigo ... o cliente é teu, o contrato é seu, e ...

 

Já colaborou com projetos opensource? Já pensou/desejou ter algum código/serviço/utilitário seu disponibilizado para público?

 

Sim, já colaborei, e você ? cadê sua API REST open-source que todo mundo usa ? cadê sua aplicação que faz uma deleção usando /DELETE, /PUT usando AJAX, controlando a paginação, e tudo mais ?

 

Eu tenho várias aqui fazendo o básico e resolvendo o problema ...

Open-Source ? assim que eu concluir o código daqui alguns dias eu posso disponibilizar cada linha escrita, imagem, detalhe, etc etc .... mas e o teu ?

[Evandro Oliveira 331]

Por concordar plenamente com você, que eu uso [inline]<button>[/inline].

 

O botão de enviar/resetar um formulário não é uma entrada de informação. A entrada de informação são os dados contidos no formulário por si só. É exatamente a flexibilidade do [inline]<button>[/inline] que permite esta abordagem.

 

Para se realizar com [inline]<input/>[/inline], o texto a ser exibido é o contido em value.

<form action="" method="post">
    <input type="submit" name="do" value="Editar">
    <input type="submit" name="do" value="Excluir">

Agora, imagine que vamos dar suporte multi-idioma à nossa aplicação

<form action="" method="post">
    <input type="submit" name="do" value="<?=_('btn_edit')?>">
    <input type="submit" name="do" value="<?=_('btn_remove')?>">

http://php.net/function.gettext

 

Vamos supor que a ação esteja dentro de uma função

function remover(PDO $conn) {
    $stmt = $conn->prepare('delete from tabela where id = ?');
    $stmt->execute([$_POST['id']);
}

call_user_func($_POST['do'], $pdoConn);

Para mantermos a flexibilidade, as nossas funções teriam que ser escritas com http://php.net/eval ou teríamos que mapear o nome da função para o valor que se supõe que esteja no botão

$actions = [
    _('btn_edit') => 'editar',
    _('btn_remove') => 'remover'
];

call_user_func($actions[$_POST['do']], $pdoConn);

 

Pow, que foda, mas eu dou solução para o problema que o cliente tem.

 

Um cara quer ali um controle financeiro, eu vou fazer API disso pra que ? é um programa que roda online, só isso, o único problema que ele quer resolver é disponibilizar seu acesso em qualquer lugar, só isso, não quer criar API nem nada disso não meu.

 

Eu até entendo o que você fala, mas caramba ... eu faço o negócio funcionar, sacou ? se tu gosta ai de fazer JS, de sei lá o que, e de ficar programando ai coisas que nem precisa e vai dar o mesmo resultado pro cliente (porém com MAIS CUSTO), ai é problema teu saka ? eu curto fazer desse jeito, NÃO é gambiarra, funciona direitinho, e nunca levei um ataque em massa que meu deus nossa senhora.

 

Eu só resolvo um problema, quando eu tenho um problema. Se tu gosta ai de ficar fazendo coisa que o cara nem vai precisar, problema seu também, ai é contigo ... o cliente é teu, o contrato é seu, e ...

 

 

Sim, já colaborei, e você ? cadê sua API REST open-source que todo mundo usa ? cadê sua aplicação que faz uma deleção usando /DELETE, /PUT usando AJAX, controlando a paginação, e tudo mais ?

 

Eu tenho várias aqui fazendo o básico e resolvendo o problema ...

Open-Source ? assim que eu concluir o código daqui alguns dias eu posso disponibilizar cada linha escrita, imagem, detalhe, etc etc .... mas e o teu ?

http://fluxodecaixa.com.br

[Andrey Knupp Vital 136]

http://fluxodecaixa.com.br

Show man, parece bem bacana.

Enfim, que bom que tu faz isso tudo, resolve ai teus problemas de RESTful.

[mangakah 217]

Realmente BUTTON é bem mais flexível, pois permite HTML dentro, enquanto INPUT é um elemento void. Mas isso pode ser melhor contornado usando LABEL, embora seja necessário usar CSS para esconder o INPUT... :-/

 

Ex.:

<!DOCTYPE html>
<style type="text/css">
    input[type="submit"] {
        display: none;
    }
</style>
<form method="post" action="">
  <input type="hidden" name="id" value="1">
  <label for="btnEdit1">Editar</label>
  <input class="btnEdit" id="btnEdit1" type="submit" name="action" value="edit">
  <label for="btnDelete1">Excluir</labe>
  <input class="btnDelete" id="btnDelete1" type="submit" name="action" value="delete">
</form>

[Evandro Oliveira 331]

 

Realmente BUTTON é bem mais flexível, pois permite HTML dentro, enquanto INPUT é um elemento void. Mas isso pode ser melhor contornado usando LABEL, embora seja necessário usar CSS para esconder o INPUT... :-/

 

Ex.:

<!DOCTYPE html>
<style type="text/css">
    input[type="submit"] {
        display: none;
    }
</style>
<form method="post" action="">
  <input type="hidden" name="id" value="1">
  <label for="btnEdit1">Editar</label>
  <input class="btnEdit" id="btnEdit1" type="submit" name="action" value="edit">
  <label for="btnDelete1">Excluir</labe>
  <input class="btnDelete" id="btnDelete1" type="submit" name="action" value="delete">
</form>

 

 

Excelente. Alternativas são sempre muito bem vindas. :)

 

Passamos para o ponto de conceito, concepção e entendimento. Eu não entendo que o clique em um botão seja um dado a ser inserido.

 

A propósito, quando você utilizaria um [inline]<button type="submit">[/inline] ?

[Alaerte Gabriel 662]

Que complicação danada por causa de um GET ou DELETE putz :sick:

 

Esse bla bla bla bla faz uma confusão na <head> do autor do tópico que vocês nem imaginam, perde o foco.

 

Caro amigo autor do tópico, utilize o GET mesmo, apenas saiba trabalhar os dados corretamente, para que não tenha problemas com segurança já que esse é o seu temor, e acrescento que em nenhum dos métodos você estará 100% seguro, além de FIREBUG que por aí acima fora citado, existe um programa de teste chamado acunetix web vulnerability scanner que consiste em explorar falhas e métodos em uma aplicação.

[mangakah 217]

A propósito, quando você utilizaria um [inline]<button type="submit">[/inline] ?

 

Eu entendo que se BUTTON tem um atributo value, então ele está entrando com uma informação, ou seja, está fazendo às vezes de INPUT. A meu ver isso quebra a semântica. Então eu usaria button com type=submit sempre que não houvesse a necessidade de colocar um value nesse button, como editar/deletar apenas um registro ou submeter um formulário simples, por exemplo.

[Bruno Augusto 417]

O ruim da tag input para botões é que ela é meio limitada no quesito estilização.

 

Com a tag button e um pouquinho de CSS você consegue fazer botões completamente diferentes de um botão padrão, sem quebrar a semântica e com compatibilidade inter-navegadores bastante aceitável coisa que com input é no mínimo tortuoso.

 

Quanto ao pequeno desvio de Santos pro Pará que esse tópico tomou, querem uma divisão?

[cristianoolv 93]

Eu só resolvo um problema, quando eu tenho um problema.

:joia: Como dizia meu professor de história, o se não existe.

 

 

O ruim da tag input para botões é que ela é meio limitada no quesito estilização.

Desconheço.

 

Santos pro Pará, c quis dizer Amazonas pro Acre né ? :mellow: :P

[Bruno Augusto 417]

Desconheço.

 

Tá certo que não manjo muito de design nem de CSS e meu comentário foi baseado em experiências que tive anos atrás, muito antes desses frameworks CSS onde usar a tag input para um botão e fazê-la ser bastante flexível, seja por adicionar um ícone, trocar a aparência, fazê-lo ser fluido e etc. era dureza.

 

Lembro que o Micox até postou um artigo no blog dele incentivando o uso da tag button.

 

Santos pro Pará, c quis dizer Amazonas pro Acre né ? :mellow: :P

 

Não por dois motivos. Primeiro que o tópico desvirtuou pra baralho e segundo que o Acre non ecziste. :lol:

[verneklavor 0]

Bom dia,

 

se está c/ medo de utilizar GET por questões de segurança, basta codificar as variaveis c/ MD5 por exemplo.

[Evandro Oliveira 331]

auhauhauhauahuahuahuahuahuahauhauhauhaua

 

desculpa, não aguentei.