Ele viola as idéias do REST, ou convenções aceitas, de ter modelos diferentes para GET / PUT / POST no mesmo URL?

Um exemplo:

Considere um recurso simples encontrado em api / things

Eu posso criar uma coisa:

POST api/things 
with body = { Name: "New Thing" }

Isso me devolve uma coisa junto com a localização

{ Id: 500, Name: "New Thing", Links: ["api/things/500"] }
Location Header: api/things/500

Eu posso entender isso com:

GET api/things/500

e eu vou conseguir

{ Id: 500, Name: "New Thing", Links: ["api/things/500"] }

Se eu quiser atualizá-lo: PUT api / things / 500

{ Name: "Updated Thing", IsActive: false }

Existem "regras" neste exemplo que estão ocultas por trás dos diferentes modelos.

Ao criar, você não pode especificar a configuração Id ou IsActive. O ID é gerado pelo servidor sempre inicia como ativo.Você não pode atualizar um ID e, portanto, o "link" que o utiliza, para que o modelo PUT não contenha um campo de ID.

Uma forte crítica a isso: não posso fazer um POST para criar um novo, altere o campo Nome e coloque-o novamente em Atualizá-lo. Eu precisaria saber para remover os campos Id e links. Eu poderia "ser liberal no que aceito" e permitir que os IDs e os links estivessem na solicitação de PUT, mas preciso tomar decisões adicionais como "será 400 se o Id / Link que eles enviarem for diferente? E "é 400 se eles não enviarem um ID / Link?". Se a API afirma aceitar esses campos no PUT, isso pode ser visto como um contrato que eles podem ser atualizados.