Nada de esto es autoritario (ya que REST no tiene un significado exacto). Pero desde el documento original en REST, una URL completa (que no termina en /) nombra un recurso, mientras que una termina en una barra inclinada '/' es un grupo de recursos (probablemente no redactado así).

Se supone que el GET de una URL con una barra al final enumera los recursos disponibles.

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

Se supone que un PUT en una URL con una barra sustituye todos los recursos.

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

Un BORRAR en una URL con una barra debe eliminar todos los recursos

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

Se puede acceder posteriormente a un POST en una URL con una barra oblicua para crear un nuevo recurso. Para ser conforme, el nuevo recurso debería estar en este directorio (aunque muchas arquitecturas RESTful hacen trampa aquí).

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

etc.

La página wiki sobre el tema parece explicarlo bien:

Consulte el ejemplo enlace .

Does anyone know the definitive answer?

No hay uno, ya que no hay un documento oficial sobre lo que se requiere para que un servicio se considere REST.

Dicho esto, permitiría la barra inclinada simplemente para facilitar su uso. Aunque técnicamente hablando, esto podría verse como intentar acceder a un perro con una identificación nula; No veo que un usuario haga este salto a menos que lo haya leído en su documentación. Puedo ver a un usuario que intenta escribir código en su API e incluye la barra diagonal final simplemente por costumbre y preguntándose por qué obtiene una respuesta 404 cuando quiere una lista de perros.

De dos maneras.

Método 1

Siempre use barras al final para cualquier recurso que pueda contener hijos.

Solo considera "GET" en un directorio public_html con archivos.

No es posible cuando hello.html es un archivo:

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

Pero es posible cuando hello.html es un directorio:

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

Entonces, si "hello.html" puede tener hijos, entonces siempre será "/hello.html/" y "/hello.html/index.html" (o simplemente /hello.html/) es una lista de estos niños.

Método 2

Sé "inteligente".

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

El comando de búsqueda no se preocupa por el tipo de hello.html. Directorio o archivo, a quién le importa, es el nombre de un objeto. Cuando escribimos "cp youagain.html hello.html", cp puede descubrir cómo manejar hello.html. cp es inteligente. Su servidor web es inteligente también. Tiene una biblioteca de manejo de ruta. Tiene enrutamiento. Puede hacer estadísticas y decirle si un nombre es un objeto o un directorio. Puede redirigir a bla a bla / o incluso simplemente ofrecer la misma respuesta para ambos. ¡Esto es lo increíble! camino. Tanta tecnología. ¿Quién querría simplemente concatenar cadenas de ruta cuando podríamos hacer todo eso?