Come si valuta il tradeoff tra robustezza e codice "pigro" nella progettazione dell'API?

Sarà più semplice accettare l'input rigoroso e rifiutare qualsiasi altro modulo, perché dovrai considerare solo un caso.

Dipende davvero dalle esigenze dei tuoi clienti. Hanno bisogno di flessibilità di input, ad esempio l'internazionalizzazione, o possono lavorare comodamente con un unico formato.

Sii severo in ciò che accetti. Essere liberale in ciò che accetti e essere rigoroso su ciò che ritorni, è basato su un mondo di agenti indipendenti, ad esempio server SMTP. Se un server di posta ti invia un'email difettosa e puoi salvarla, è meglio di un errore criptico per il mittente della posta.

Tuttavia, quando stai progettando un'API da utilizzare da altri programmatori, è una storia diversa. Ricevono feedback immediati quando forniscono input errati. L'altra opzione per indovinare cosa significano è molto pericolosa. Se accetti 14-12 come dicembre quattordicesimo e 14-10 ottobre quattordici, che cosa farà il tuo programma con 10-12? Meglio essere severi ed errori con uno di essi, in questo modo il tuo programma si comporterà in modo prevedibile, che è molto più importante di essere in grado di accettare tutto.

Vorrei codificare la funzione principale con un formato specifico come input. Se è presente una richiesta per aggiungere altri formati, ecc, creare una funzione per sovraccaricare il nome che converte l'oggetto data ecc nel formato prima di chiamare la funzione principale.