Devo ser permissivo de parâmetros desconhecidos?

Estou projetando uma API RESTful e enfrentando o problema do título, atualizado para maior clareza:

Devo falhar rapidamente se um cliente enviar um parâmetro não reconhecido? Por exemplo,

http://example.com/api/foo?bar=true&paula=bean

Acima, baré um parâmetro válido, mas paulanão é especificado pela API. Eu devo

Avise o cliente do erro
Falhar rápido
Ignore isto

Se eu avisar o cliente, só posso emitir um aviso para o primeiro parâmetro, pois eles podem estar enviando um número quase infinito deles e o servidor provavelmente tem coisas melhores a fazer. Da mesma forma, ao falhar, especificaria apenas o primeiro parâmetro inválido como o problema.

Prefiro falhar do que emitir um aviso para forçar o programador a tomar uma ação, pois, caso contrário, eles podem ignorar o problema e continuar desperdiçando recursos, ou acabam se culpar inadvertidamente. Não fazer nada é ainda pior a esse respeito.

Meus argumentos fazem sentido? Existe uma prática aceita em tais coisas?

rest api-design

— rath
fonte

Com base em um pequeno teste, todos os sites que eu testei simplesmente ignoram os parâmetros desconhecidos que eu os forneci.

— Bart van Ingen Schenau

@BartvanIngenSchenau Mesmo aqui. É bom para as páginas da web, mas eu não acho que é ok para uma API real

— Rath

Uma preocupação é a compatibilidade futura. Se argumentos desconhecidos forem ignorados, é possível usá-los em versões futuras de forma que os clientes possam programar para a nova API e ainda assim obter um comportamento razoável em servidores antigos.

— walpen

@walpen Esse é um ponto interessante. O uso de URLs com versão api/v1etc. cuidaria disso, mas ainda não permite atualizações incrementais. +1

— Rath

Lá, você pode encontrar alguns prós e contras da perspectiva real ao vivo: parâmetros estritos e sua API .

— Remek Ambroziak

Respostas:

Na minha opinião, você deve retornar um status de solicitação inválida, para que o cliente saiba que o que está tentando fazer não é válido. Minha opinião sobre isso é influenciada pelo conceito de que as APIs RESTful são detectáveis . Se você estiver fornecendo informações suficientes antecipadamente, o cliente nunca tentará fazer uma solicitação inválida para começar. Caso isso aconteça, há algo errado no código do cliente e, se falhar rapidamente, alertará o segundo sobre esse bug. Obviamente, essa é uma abordagem muito purista e pode não ser recomendada se sua API não for detectável.

Uma abordagem mais pragmática pode ser ignorar os parâmetros inválidos, mas, seja como for, certifique-se de documentar bem o comportamento.

— Pato de borracha
fonte

Como uma extensão: se um cliente enviar alguns parâmetros desconhecidos / somente leitura / obsoletos, isso significa que o cliente espera algum comportamento que não será cumprido. E, portanto, é perigoso executar qualquer ação. Então, eu concordo, estritamente Pedido Ruim

— Stepan Stepanov

Obrigado @StepanStepanov, mas existe a filosofia "Seja permissivo no que você aceita, explícito sobre o que você envia" subjacente a grande parte da arquitetura da web. Com isso em mente, eu poderia facilmente escrever uma resposta em oposição direta à que eu já escrevi.

— precisa

Eu pesquisei isso no Google)) E a página sobre a lei de Postel também diz que "o código que recebe informações deve aceitar informações não conformes, desde que o significado seja claro". Eu acho que, se o cliente nos enviar algum parâmetro desconhecido, seu significado não poderá ser claro. Se o cliente nos enviar um parâmetro descontinuado, é claro que não funcionará como antes e como o cliente espera. Se o cliente nos enviar um parâmetro somente leitura, é claro que não será gravado como o cliente deseja.

— Stepan Stepanov

Se você faz API pública (ou API que será usada por outra equipe), eu recomendaria o erro de retorno, como sugerido pelo @RubberDuck.

Se sua API será consumida apenas dentro de sua equipe (ou apenas por você), talvez seja mais fácil ignorar campos extras (por exemplo, requer menos código e mais facilidade).

— Konstantin Petrukhnov
fonte