Nessuna di queste è autorevole (poiché REST non ha un significato esatto). Ma dal documento originale su REST un URL completo (non terminato in /) nomina una risorsa, mentre una termina in una barra '/' è un gruppo di risorse (probabilmente non formulato in quel modo).

Un GET di un URL con una barra alla fine dovrebbe elencare le risorse disponibili.

GET http://example.com/dogs/          /* List all the dogs resources */

Un PUT su un URL con una barra dovrebbe sostituire tutte le risorse.

PUT http://example.com/dogs/          /* Replace all the dogs resources */

Un ELIMINA su un URL con una barra dovrebbe eliminare tutte le risorse

DELETE http://example.com/dogs/       /* Deletes all the dogs resources */

Si suppone che un post su un URL con una barra per creare una nuova risorsa possa essere successivamente consultato. Per essere conforme, la nuova risorsa dovrebbe essere in questa directory (anche se molte architetture RESTful imbrogliano qui).

POST http://example.com/dogs/        /* Creates a new dogs resource (notice singular) */

ecc.

La pagina wiki sull'argomento sembra spiegarla bene:

Vedi l'esempio link .

Does anyone know the definitive answer?

Non ce n'è uno in quanto non esiste un documento ufficiale su ciò che è necessario affinché un servizio sia considerato RESTful.

Detto questo, avrei permesso la barra finale semplicemente per facilità d'uso. Mentre tecnicamente parlando questo potrebbe essere visto come il tentativo di accedere a un cane con un ID nullo; Non vedo un utente che effettua questo salto a meno che non lo abbia letto nella documentazione. Posso vedere un utente che tenta di scrivere codice contro la tua API e include la barra finale semplicemente per abitudine e si chiede perché ottengono una risposta 404 quando vogliono un elenco di cani.

Due modi.

Metodo 1

Usa sempre le barre finali per qualsiasi risorsa che potrebbe contenere figli.

Considera "GET" in una directory public_html con i file.

Non possibile quando hello.html è un file:

/hello.html
/hello.html/youagain.html

Ma possibile quando ciao.html è una directory:

/hello.html/     (actually /hello.html/index.html)
/hello.html/youagain.html

Quindi se "hello.html" può avere figli allora è sempre e per sempre "/hello.html/" e "/hello.html/index.html" (o semplicemente /hello.html/) è un elenco di questi bambini.

Metodo 2

Sii "intelligente".

$ find
.
./hello.html
./hello.html/index.html

Il comando find non interessa il tipo di hello.html. Directory o file, a chi importa, è il nome di un oggetto. Quando scriviamo "cp youagain.html ciao.html", cp può capire come gestire hello.html. cp è intelligente. Anche il tuo server web è intelligente. Ha una libreria per la gestione dei percorsi. Ha routing. Può stat e dirti se un nome è un oggetto o una directory. Può reindirizzare blah a blah / o anche solo servire la stessa risposta per entrambi. Questo è fantastico !!! modo. Tanta tecnologia. Chi vorrebbe mai concatenare semplicemente stringhe di path quando potremmo fare tutto questo ???