HTML não serve para REST

{ April 18th, 2008 }


cmilfont

Autor: cmilfont

O maior problema de disponibilizar uma aplicação como API via REST é a construção de aplicações Mashups com formulários HTML sem usar um “proxy” server-side.

Digamos que eu queira construir uma aplicação apenas cliente acessando uma API implementada em REST segundo os “bons constumes”. Segundo a especificação do HTML, o form só possuem dois tipos de método HTTP, o POST e o GET. Isso inviabiliza a submissão de operações de alterações de um recurso pelo método PUT e de exclusão pelo método DELETE. O Fernando Chucre dos Horizontes Digitais me alertou para consultar a especificação do HTML depois que levei uma surra ao tentar implementar isso com form, eu pensei que era problema no apache e estava tentando “habilitar” os outros métodos por não saber que o Form HTML não permite.

Funciona usando AJAX caso a aplicação vá funcionar no mesmo host da API, mas se minha aplicação está hospedada em outro local já não funciona. Outra estratégia que não funciona é Scripttag porque esse só usa GET para adicionar um script no Head da página.

Por enquanto não imaginei uma forma crossbrowser de acessar um recurso remoto pelos métodos PUT e DELETE que não seja usando um Proxy no mesmo host que está hospedado a aplicação consumidora do recurso. Na spec OpenSocial você tem o método makeRequest dessa forma.

Caso alguém tenha uma idéia para contornar esse problema pode comentar aqui.

Categories: Mashup, REST, web2.0 ~ ~ Trackback


Assine os comentários deste artigo.


6 Responses to “HTML não serve para REST”

  1. 1
    Rafael Ponte

    Levar uma surra dessas revigora a alma 😡

  2. 2
    Bruno Pereira

    Oi Cristiano, vc ainda não me conhece, mas assim como você eu sou colunista da Java Magazine. Este mês inclusive tem um artigo meu sobre REST na revista :)

    Eu também descobri há alguns meses essa limitação do HTML só enviar requisições GET e POST. O XmlHttpRequest eu sei que permite qualquer método HTTP, mas foi bom ver por aqui que ele não permite realizar requisições em outro host. Eu não sabia disso.

    Com esta restrição, realmente só dá para fazer estas requisições REST usando um proxy para encaminhar as requisições. Uma possibilidade também é hospedar o javascript consumidor dos serviços REST no mesmo host dos serviços.

    Ah, e uma implementação interessante de proxy poderia utilizar o header x-http-method-override. Este header é comumente utilizado para contornar limitações de clientes ou servidores que não possam utilizar HTTP PUT e DELETE. Nestes casos é feita uma requisição POST, e o header x-http-method-override define qual é o método HTTP desejado.

    Você poderia mandar do formulário o valor deste header como parâmetro e aí o proxy gravaria o mesmo como header da requisição, ou então montaria uma requisição HTTP PUT ou DELETE através do proxy. Esta é uma forma razoavelmente limpa de contornar o problema.

    Legal o seu blog, vou adicionar no meu Reader.

    []’s

    Bruno

  3. 3
    Rodrigo

    Pode usar o POST sobrecarregado para contornar esse problema, enviando como parâmetro o method que deseja executar, mas o HTML 5 e XHTML 1.1 (se não me engano), ambos ainda em draft, aceitam uso de PUT e DELETE.

  4. 4
    cmilfont

    Olá @Rodrido, procurei na spec do XHTML 1.1 e do HTML5 e não vi suporte a PUT e DELETE, tem algum link sobre isso?

  5. 5
    Rodrigo

    Eu li a informação no livro RESTful Webservices, mas me enganei de versão, é o XHTML 5 que no DOCTYPE vai como xhtml111.dtd por isso fiz confusão.
    Segue links:
    http://www.whatwg.org/specs/
    http://www.whatwg.org/specs/web-forms/current-work/

  6. 6
    Marcos Lopes

    Uma forma de burlar o “Same origin policy” (consumir recursos de outro dominio) é o CORS: http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing

Leave a Reply