Schema URL amichevole?

Question

Una delle tante cose che mi sono mancate dal mio servizio di scraper che ho impostato la scorsa settimana sono URL graziosi. In questo momento il parametro utente viene passato allo script con ? U = , che è un sintomo di un hack pigro (che lo script è certamente). Tuttavia, ho pensato di rifarlo e vorrei ricevere un feedback sulle opzioni disponibili. In questo momento ci sono due pagine, aggiornamento e grafico, che forniscono informazioni all'utente. Ecco le due possibilità che mi sono venute in mente. quot &; & 1234 quot; è il numero ID utente. Sfortunatamente per motivi tecnici il nome utente non può essere utilizzato:

• http: & // lt; tld > / update / 1234
• http: & // lt; tld > / chart / 1234

o

• http: & // lt; tld > / 1234 / update
• http: & // lt; tld > / 1234 / chart

L'opzione n. 1, concettualmente, chiama l'aggiornamento con l'ID utente. L'opzione n. 2 fornisce un verbo per operare su un ID utente.

Dal punto di vista della coerenza, che ha più senso?

---

Un'altra opzione menzionata è

• http: & // lt; tld > / user / 1234 / update
• http: & // lt; tld > / user / 1234 / chart

Fornisce spazio per pagine non relative a un utente specifico. cioè.

• http: & // lt; tld > / stats

Answer 1

Sarei delicatamente propenso a guidare con userid - opzione # 2 - poiché (ciò che esiste) la struttura della directory è di due diverse funzioni sui dati di un utente. È il grafico dell'utente e l'aggiornamento dell'utente.

È un aspetto piuttosto secondario, tuttavia, senza sapere se ci sono piani per un'espansione significativa della funzionalità di questa cosa.

• Tutto andrà avanti con funzioni aggiuntive foo e bar and baz per i singoli utenti? In tal caso, l'opzione n. 2 diventa più attraente per il motivo sopra riportato: l'id utente è i dati di base, è logico iniziare con esso semanticamente.
• Stai per aggiungere funzionalità non guidata dall'utente? Dirigere con una directory di intestazione potrebbe avere senso allora - / user / 1234 / update, / user / 1234 / chart, / question / 45678 / activity, / question / 45678 / stats, ecc.

Answer 2

Se segui questo schema, diventa semplice fermare i robot (ben educati) dallo spidering del tuo sito:

 http://< tld >/update/1234
 http://< tld >/chart/1234

Questo perché è possibile impostare un file /robots.txt per contenere:

 Disallow /update/
 Disallow /chart/

Per me questo è un bel bonus che viene spesso trascurato.

Answer 3

L'opzione n. 1 corrisponde agli esempi comuni di ASP.NET MVC. Alcuni degli esempi su Model View Controller ha la forma {controller} / {azione} / {id}. La

Personalmente mi piace questo stile, perché mantiene lo stesso utente, ma ti fornisce informazioni specifiche su di loro.

• http: & // lt; tld > / 1234 / update
• http: & // lt; tld > / 1234 / chart

Se andassi dall'altra parte, mi aspetterei di poter vedere tutto in / update o / chart e poi restringere l'utente.

Vai con quest'ultimo; Gli URL devono essere gerarchici (o, almeno, gli utenti li leggono in questo modo per analogia ai percorsi delle directory locali). Il focus qui è su diverse viste di un utente specifico, quindi & Quot; user & Quot; è il concetto più generale e dovrebbe apparire per primo.

Ho appena risposto alla domanda " Come si fa strutturi i tuoi percorsi URL? " con le mie opinioni su come rendere gli URL RESTful, hackerabili e facili da usare. Penso che sarebbe meglio collegare che scrivere qualcosa di simile in questa domanda, da qui il collegamento.

Sono d'accordo dal punto di vista del contesto, l'applicazione seguita dai parametri ha molto più senso per me della chiave surrogata per un elemento seguita dal contesto di quale sia l'elemento. Alla fine, suggerirei quale sia il più naturale da programmare per te.

La convenzione dice object / verb / ID, quindi dovrebbe essere:

http: & // lt; tld > / user / update / 1234

(Ho appena notato che corrisponde alla tua domanda aggiornata :)

Quindi sì, # 3 è la scelta migliore.

Questo supporta operazioni non utente come menzionato (stats /), nonché operazioni multiutente:

http: & // lt; tld > / user / list /

Se esiste un modo per elencare gli utenti, introdurrei un segmento di utenti:

http://< tld >/users/ <--- user list
http://< tld >/users/1234/ <--- user profile, use overloaded POST on this to update.
http://< tld >/users/1234/chart/ <--- user chart

Se riesci a vedere solo i tuoi dettagli, cioè gli utenti sono invisibili l'uno all'altro, non hai bisogno dell'ID utente poiché puoi inferirlo dalla sessione, nel qual caso:

http://< tld >/user/ <--- user profile, use overloaded POST on this to update.
http://< tld >/user/chart/ <--- user chart

Answer 4

Answer 5

Answer 6

Personalmente mi piace questo stile, perché mantiene lo stesso utente, ma ti fornisce informazioni specifiche su di loro.

• http: & // lt; tld > / 1234 / update
• http: & // lt; tld > / 1234 / chart

Se andassi dall'altra parte, mi aspetterei di poter vedere tutto in / update o / chart e poi restringere l'utente.

Answer 7

Vai con quest'ultimo; Gli URL devono essere gerarchici (o, almeno, gli utenti li leggono in questo modo per analogia ai percorsi delle directory locali). Il focus qui è su diverse viste di un utente specifico, quindi & Quot; user & Quot; è il concetto più generale e dovrebbe apparire per primo.

Answer 8

Vai con quest'ultimo; Gli URL devono essere gerarchici (o, almeno, gli utenti li leggono in questo modo per analogia ai percorsi delle directory locali). Il focus qui è su diverse viste di un utente specifico, quindi & Quot; user & Quot; è il concetto più generale e dovrebbe apparire per primo.

Answer 9

Ho appena risposto alla domanda " Come si fa strutturi i tuoi percorsi URL? " con le mie opinioni su come rendere gli URL RESTful, hackerabili e facili da usare. Penso che sarebbe meglio collegare che scrivere qualcosa di simile in questa domanda, da qui il collegamento.

Answer 10

Answer 11

Answer 12

Ho appena risposto alla domanda

Answer 13

Sono d'accordo dal punto di vista del contesto, l'applicazione seguita dai parametri ha molto più senso per me della chiave surrogata per un elemento seguita dal contesto di quale sia l'elemento. Alla fine, suggerirei quale sia il più naturale da programmare per te.

Answer 14

La convenzione dice object / verb / ID, quindi dovrebbe essere:

http: & // lt; tld > / user / update / 1234

(Ho appena notato che corrisponde alla tua domanda aggiornata :)

Quindi sì, # 3 è la scelta migliore.

Questo supporta operazioni non utente come menzionato (stats /), nonché operazioni multiutente:

http: & // lt; tld > / user / list /

Answer 15

Se esiste un modo per elencare gli utenti, introdurrei un segmento di utenti:

http://< tld >/users/ <--- user list
http://< tld >/users/1234/ <--- user profile, use overloaded POST on this to update.
http://< tld >/users/1234/chart/ <--- user chart

Se riesci a vedere solo i tuoi dettagli, cioè gli utenti sono invisibili l'uno all'altro, non hai bisogno dell'ID utente poiché puoi inferirlo dalla sessione, nel qual caso:

http://< tld >/user/ <--- user profile, use overloaded POST on this to update.
http://< tld >/user/chart/ <--- user chart