Como você implementa formulários de “edição” de recursos de forma RESTful?

Question

Estamos tentando implementar uma API REST para um aplicativo que temos agora.Queremos expor capacidades de leitura/gravação para vários recursos usando a API REST.Como implementamos a parte "formulário" disso?Eu entendo como expor a "leitura" de nossos dados criando URLs RESTful que funcionam essencialmente como chamadas de método e retornam os dados:

GET /restapi/myobject?param=object-id-maybe

...e um documento XML representando alguma estrutura de dados é retornado.Multar.

Mas, normalmente, em uma aplicação web, uma “edição” envolveria duas solicitações:um para carregar a versão atual dos recursos e preencher o formulário com esses dados e outro para postar os dados modificados de volta.

Mas não entendo como você faria a mesma coisa com métodos HTTP para os quais o REST está mapeado.É um PUT, certo?Alguém pode explicar isso?

(Considerações adicionais:A UI seria feita principalmente com AJAX)

-- Atualizar:Isso definitivamente ajuda.Mas ainda estou um pouco confuso sobre o lado do servidor?Obviamente, não estou lidando apenas com arquivos aqui.No servidor, o código que responde às solicitações deve filtrar o método de solicitação para determinar o que fazer com ele?Essa é a "alternância" entre leituras e gravações?

Answer 1

Se você estiver enviando os dados via HTML simples, estará restrito a fazer um formulário baseado em POST.O URI para o qual a solicitação POST é enviada não deveria seja o URI do recurso que está sendo modificado.Você deve fazer POST em um recurso de coleção que ADICIONE um recurso recém-criado a cada vez (com o URI do novo recurso no Localização cabeçalho e um 202 código de status) ou POST para um recurso atualizador que atualiza um recurso com um URI fornecido no conteúdo da solicitação (ou cabeçalho personalizado).

Se estiver usando um objeto XmlHttpRequest, você poderá definir o método como PUT e enviar os dados ao URI do recurso.Isto também pode funcionar com formulários vazios se o servidor fornecer um URI válido para o recurso ainda inexistente.O primeiro PUT criaria o recurso (retornando 202).Os PUTs subsequentes não farão nada se forem os mesmos dados ou modificarão o recurso existente (em ambos os casos, um 200 é retornado a menos que ocorra um erro).

Answer 2

Existem muitas alternativas diferentes que você pode usar.Uma boa solução é fornecida no wiki de microformatos e também foi referenciado pela equipe RESTful JSON.O mais próximo que você pode chegar de um padrão, na verdade.

 Operate on a Record

GET /people/1
    return the first record 
DELETE /people/1
    destroy the first record 
POST /people/1?_method=DELETE
    alias for DELETE, to compensate for browser limitations 

GET /people/1/edit
    return a form to edit the first record 
PUT /people/1
    submit fields for updating the first record 
POST /people/1?_method=PUT
    alias for PUT, to compensate for browser limitations 

Answer 3

Acho que você precisa separar os serviços de dados da interface da web.Ao fornecer serviços de dados, um sistema RESTful é totalmente apropriado, incluindo o uso de verbos que os navegadores não suportam (como PUT e DELETE).

Ao descrever uma UI, acho que a maioria das pessoas confunde "RESTful" com "URLs agradáveis ​​e previsíveis".Eu não ficaria tão preocupado com uma sintaxe de URL puramente RESTful ao descrever a UI da web.

Answer 4

O carregamento deve ser apenas uma solicitação GET normal, e o salvamento de novos dados deve ser um POST para a URL que atualmente contém os dados...

Por exemplo, carregue os dados atuais de http://www.example.com/record/matt-s-example e então, altere os dados e POST de volta para o mesmo URL com os novos dados.

Uma solicitação PUT pode ser usada ao criar um novo registro (ou seja,COLOQUE os dados em uma URL que não existe atualmente), mas na prática apenas POSTing é provavelmente uma abordagem melhor para começar.