Qual è il vantaggio degli URI delle risorse globali (ovvero indirizzabilità)?
https://stackoverflow.com/questions/147172
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
Qual è il vantaggio di fare riferimento a risorse usando URI univoci a livello globale (come fa REST) ??rispetto a un formato ID proprietario?
Ad esempio:
Nel primo approccio l'intero URL è l'ID. Nel secondo approccio, solo 5 è l'ID. Qual è il vantaggio pratico del primo approccio rispetto al secondo?
Perché REST (sembra) fare di tutto per sostenere il primo approccio?
- EDIT:
La mia domanda era confusa perché faceva davvero due domande separate:
- Qual è il vantaggio di indirizzabilità?
- Qual è la differenza tra i due moduli URI visti sopra.
Ho risposto a entrambe le domande di seguito usando il mio post.
Soluzione 2
Risponderò alla mia domanda:
1) Perché gli URI sono importanti?
Citerò da RESTful Web Services di Leonard Richardson e Sam Ruby (ISBN: 978-0-596-52926-0) :
Prendi in considerazione un URI reale che denomina una risorsa nella categoria "directory di risorse" medusa ": http://www.google.com/search?q=jellyfish . Quella ricerca di meduse è altrettanto un vero URI come http://www.google.com . Se HTTP non era indirizzabile o se Google il motore di ricerca non era un'applicazione web indirizzabile, non avrei potuto pubblicarla URI in un libro. Dovrei dirti: "Apri una connessione web su google.com, digita" meduse " nella casella di ricerca e fai clic sul pulsante "Ricerca Google".
Questa non è una preoccupazione accademica. Fino alla metà degli anni '90, quando ftp: // URI è diventato popolare per la descrizione di file su siti FTP, la gente ha dovuto scrivere cose come: “Avvia una sessione FTP anonima su ftp.example.com. Poi passa alla directory pub / files / e scarica il file file.txt. ”Creati gli URI FTP indirizzabile come HTTP. Ora le persone scrivono semplicemente: “Scarica ftp: // ftp.example.com/pub/files/file.txt. ”I passaggi sono gli stessi, ma ora lo sono può essere eseguito dalla macchina.
[...]
L'indirizzamento è una delle cose migliori delle applicazioni web. Lo rende facile per i clienti utilizzano i siti Web in modi che i designer originali non hanno mai immaginato.
2) Qual è il vantaggio di indirizzabilità?
È molto più facile seguire gli URI forniti dal server che costruirli da soli. Ciò è particolarmente vero in quanto le relazioni delle risorse diventano troppo complesse per essere espresse in semplici regole. È più facile codificare la logica una volta nel server che implementarla nuovamente in numerosi client.
La relazione tra le risorse può cambiare anche se gli URI delle singole risorse rimangono invariati. Ad esempio, se Google Maps dovesse modificare la scala dei riquadri della mappa, i client che calcolano le posizioni relative dei riquadri si spezzerebbero.
3) Qual è il vantaggio degli URI rispetto agli ID personalizzati?
Gli ID personalizzati identificano una risorsa in modo univoco. Gli URI fanno un ulteriore passo dicendoti dove trovarlo. Questo semplifica la logica del client.
Altri suggerimenti
La cosa principale quando vedo che l'uri è così un utente normale sarebbe in grado di ricordare quell'uri.
Noi geek stiamo bene con punti interrogativi e otteniamo variabili, ma se qualcuno ricorda http: // www. host.com/users/john anziché http://www.host. com /? view = users & amp; name = john , questo è un enorme vantaggio.
Ottimizzazione dei motori di ricerca per lo più.
A mio avviso, li rende anche più facili da ricordare e più puliti, più professionali a mio avviso.
Il primo è esteticamente più gradevole.
Tecnicamente non c'è differenza, ma usa la prima quando puoi.
Come accennato da Ólafur, la chiarezza dell'ex url è un vantaggio.
Un altro è la flessibilità di implementazione.
Diciamo che lo studente 5 cambia di rado. Se usi l'URL in stile REST hai la possibilità di pubblicare un file statico invece di eseguire il codice. In Rails è comune che la prima richiesta agli studenti / 5 crei un file html memorizzato nella cache nella radice Web. Tale file viene utilizzato per soddisfare le richieste successive senza toccare il back-end. Naturalmente, non c'è nulla di specifico in questo approccio.
L'URL successivo non lo consentirebbe. Non puoi avere variabili url (?, =) Nei nomi delle pagine statiche.
Entrambi gli URI sono validi dal punto di vista REST, tuttavia si rendono conto che le cache Web trattano i parametri di querystring in modo molto diverso.
Se desideri utilizzare la memorizzazione nella cache a tuo vantaggio, ti suggerisco di non utilizzare un parametro della stringa di query per identificare la tua risorsa.
Penso che dipenda da quanto vuoi aderire ai principi del feng shui.
