Como enviar atualizações parciais RESTful?

Question

Sam Ruby, autor de "RESTful Web Services" parece sair contra o uso de HTTP PUT para atualizações parciais: http://intertwingly.net/blog/2008/02/15/Embrace-Extend-then-Innovate

O que não está claro é como atualizações parciais deve ter lugar. Como eu comentei na parte inferior do seu blog, não está claro como o uso PATCH HTTP é melhor do que usar um "documento de patch" contra PUT HTTP.

É interessante notar que, apesar de Sam sai contra o mau uso HTTP PUT ele parece não defendem o uso de HTTP PATCH quer.

Como se deve enviar atualizações parciais RESTful?

Answer 1

Como você pode ver a partir dos comentários do post você referenciou não há nenhuma acordados maneira de fazer atualizações parciais. Se pesos pesados ??como Sam Ruby, Joe Gregario, Mark Nottingham, Mark Pilgrim, Bill de Hora, etc não pode chegar a um acordo, o que espero que nós temos.

Tanto quanto eu estou preocupado, eu não me preocuparia muito. Criar uma atualização de tipo de mídia parcial que funciona para você, use PATCH para indicar sua intenção e quando acordo é finalmente chegaram em um tipo geral de mídia fim, mudar o seu servidor para aceitar ambos os formatos.

Seja grato que, se o pior pecado seus commits API REST está abusando PUT / PATCH, então você está fazendo muito bem.

Answer 2

Agora é ano de 2013 - você deve usar patch para atualizações parciais - ou usando json-patch (ver http : //tools.ietf.org/html/rfc6902 ou http: //www.mnot.net/blog/2012/09/05/patch ) ou os documentos XML-patch (ver http://tools.ietf.org/html/rfc7351 ). Na minha opinião, porém, json-patch é o mais adequado para o seu tipo de dados de negócios.

PATCH com documentos remendo JSON / XML tem a semântica para a frente muito estreito para atualizações parciais. Se você começar a usar POST, com cópias modificadas do documento original, para atualizações parciais em breve você executar em problemas onde quer valores em falta (ou melhor, os valores nulos) para representar o "Ignorar esta propriedade" ou "definir essa propriedade para o valor vazio" - e que conduz um buraco de coelho de soluções hackeados que no final vai resultar em seu próprio tipo de formato de patch

.

Você pode encontrar uma resposta mais aprofundada aqui: http://soabits.blogspot.dk/2013/01/http-put-patch-or-post-partial-updates.html .

Update:? É este o RPC

Bem, se você definir RPC como enviar comandos para um servidor, então qualquer e todas as operações HTTP são chamadas RPC - se você receber um recurso, colocar uma nova representação ou excluí-lo novamente - cada um deles consiste de um envio de um comando ( verbo) GET / PUT / DELETE etc. e uma carga útil opcional. Acontece que o grupo HTTP de trabalho (ou quem quer que seja) introduziu um novo patch verbo que permite aos clientes fazer atualizações parciais a um recurso.

Se qualquer outra coisa do que enviar a representação completa para o servidor é considerado estilo RPC, então, por definição, atualizações parciais podem não ser RESTful. Pode-se optar por ter este ponto de vista, mas as pessoas por trás da infra-estrutura web diz de forma diferente -. E tem assim definido um novo verbo para este fim

RPC é mais sobre chamadas de método de tunelamento através de HTTP de uma forma que é invisível aos intermediários na web - por exemplo usando SOAP para envolver nomes de métodos e parâmetros. Estas operações são "invisíveis", já que não existem normas que definem os métodos e parâmetros dentro da carga útil.

Compare isso com PATCH com o tipo de mídia aplicação / json-patch - a intenção da operação é claramente visível para qualquer intermediário na web desde o PATCH verbo tem um significado bem definido e a carga é codificado em outro público bem definido formato disponível de propriedade da autoridade comum na web (IETF). O resultado líquido é total visibilidade para todos e nenhuma aplicação específica semântica secretos.

RESTO é também sobre a "reutilização acidental", que é exatamente o que PATCH com application / json-patch é - reutilizando uma norma existente em vez de inventar protocolos específicos de aplicativos que fazem mais ou menos o mesmo

.

Answer 3

Em vez de home-se formando um tipo de atualização de mídia parcial e usando o método PATCH ainda-não-padrão, você poderia dar partes de seus recursos a sua própria URI.

Answer 4

HTTP PATCH agora tem um RFC - HTTP PATCH RFC