In un'API REST, dovresti correggere l'input dell'utente sul lato server?

Sono d'accordo con la modifica non silenziosa dell'input dell'utente, potrebbe causare confusione e non riflette perfettamente i dati JSON inviati dall'utente finale.

Sebbene la verifica dell'input dell'utente sul lato client possa essere aggirata, è comunque una mossa saggia mostrare all'utente che il suo url verrà modificato prima che venga consumato.

In ogni caso, verifica sempre l'input lato server, perché potresti assumere che i dati (in questo caso l'url) siano ben formati, ma l'utente ha il controllo completo sull'interfaccia utente e potrebbe inviare dati difettosi che risultano in un cattivo errore del server.

Per me c'è un chiaro vincitore.

Dovresti sempre chiederti chi è responsabile di cosa? Per me, l'API Rest (e qualsiasi API) deve essere mantenuta semplice, non aggiungere mai comportamenti al di fuori di quanto ci si aspetta da essa, in questo scenario, l'API ha il ruolo di memorizzare i dati per l'ultimo utilizzo, quindi no, non correggere silenziosamente .

Inoltre, se aggiungete questa responsabilità all'API, dove tracciate la linea di cosa dovrebbe essere corretto e cosa no?

Se hai bisogno di coerenza sul lato client, aggiungi una classe nell'API consumer che gestisce questo tipo di problemi e riutilizzala ovunque utilizzi l'API.

Non vedo un problema in questo caso specifico poiché il riferimento all'URL è ben noto. Il tuo servizio non dovrebbe avere problemi ad accettare facebook.com/foobar o https://www.facebook.com/foobar come input valido.

Sai che l'URL fa riferimento a una pagina di Facebook, le pagine di Facebook possono sempre utilizzare HTTPS e Facebook eseguirà il reindirizzamento se www non è specificato.

Non modificherei l'input dell'utente; Vorrei semplicemente

• convalidare che corrisponda al formato di un URL
  • aggiungi uno schema mancante solo nel test per la convalida, in modo che i dati realmente non validi ( facebook=com\foobar ) possano essere rifiutati
• memorizza tutto ciò che l'utente ti ha dato così com'è
• formatta in modo appropriato (aggiungi https:// mancante) durante il rendering

Se l'utente ha bisogno di modificare l'URL in futuro, può essere presentato con esattamente quello che ha inserito e non sarà sorpreso da eventuali modifiche.

Puoi tenere conto delle aspettative degli utenti mentre non modifichi i dati.

C'è un'opzione che non è stata menzionata, e quella è la definizione di ciò che costituisce un input corretto per l'API. Rendi "facebook.com" un valore di campo accettabile (nota: il campo ora è NON un URL) e documentalo. Quindi non è necessaria la correzione . L'API quindi utilizza questo campo per creare un collegamento ipertestuale quando genera una risposta successiva, se necessario, proprio come userebbe una data di nascita per calcolare l'età di un utente.

Il resto del mio punto di vista segue ciò che Dan Wilson ha scritto.

Non sembra esserci una vera ragione per preferire l'uno sull'altro.

Essenzialmente hai un metodo che vuoi esporre (sarebbe bello avere alcuni nomi reali qui)

service.Method(urlLikeString)

e un codice che cambia una stringa simile a un url in un URL. Ci sono tre possibili posizioni per metterlo

1 l'applicazione

app.Method(urlLikestring)
{
    url = getUrl(urlLikestring)
    client.Method(url);
}

2 il client

app.Method(urlLikestring)
{
    client.Method(urlLikestring);
}

client.Method(urlLikestring)
{
    url = getUrl(urlLikestring)
    httpclient.post(url)
}

3 il server

client.Method(urlLikestring)
{
    httpclient.post(urlLikestring)
}


server.Method(urlLikestring)
{
    url = getUrl(urlLikestring);
    logic.Method(url);
}

A meno che non ci sia uno scenario in cui non vuoi convertire UrlLikeString, o la conversione richiede informazioni che solo uno dei livelli ha. Non fa alcuna differenza dove si inserisce la conversione.

Ovviamente devi ancora verificare che urlLikeString sia simile a url qualunque cosa tu faccia