Nada disso é autoritativo (como REST não tem significado exato). Mas a partir do documento original sobre o REST, um nome completo (que não termina em /) é um recurso, enquanto um termina em uma barra. '/' é um grupo de recursos (provavelmente não escrito assim).

Um GET de uma URL com uma barra no final deve listar os recursos disponíveis.

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

Um PUT em uma URL com uma barra deve substituir todos os recursos.

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

Um DELETE em uma URL com uma barra deve excluir todos os recursos

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

Um POST em uma URL com uma barra deve criar um novo recurso pode ser acessado subseqüentemente. Para estar em conformidade, o novo recurso deve estar neste diretório (embora muitas arquiteturas RESTful enganem aqui).

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

etc.

A página wiki sobre o assunto parece explicar bem:

Veja o exemplo link .

Does anyone know the definitive answer?

Não há um, pois não há um documento oficial sobre o que é necessário para que um serviço seja considerado RESTful.

Dito isso, permitiria a barra simples simplesmente para facilitar o uso. Embora tecnicamente falando, isso pode ser visto como uma tentativa de acessar um cachorro com um ID nulo; Eu não vejo um usuário fazendo este salto a menos que eles tenham lido em sua documentação. Eu posso ver um usuário tentando escrever código contra sua API e incluindo a barra final simplesmente pelo hábito e me perguntando por que eles recebem uma resposta 404 quando querem uma lista de cães.

Duas maneiras.

Método 1

Sempre use barras finais para qualquer recurso que possa conter crianças.

Apenas considere "GET" em um diretório public_html com arquivos.

Não é possível quando hello.html é um arquivo:

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

Mas é possível quando hello.html é um diretório:

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

Então, se "hello.html" pode ter filhos, então é sempre e para sempre "/hello.html/" e "/hello.html/index.html" (ou simplesmente /hello.html/) é uma listagem dessas crianças.

Método 2

Seja "inteligente".

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

O comando find não se importa com o tipo de hello.html. Diretório ou arquivo, quem se importa, é o nome de um objeto. Quando escrevemos "cp youagain.html hello.html", o cp pode descobrir como lidar com o hello.html. cp é inteligente. Seu servidor é inteligente também. Tem uma biblioteca de manipulação de caminho. Tem roteamento. Pode stat e dizer se um nome é um objeto ou um diretório. Ele pode redirecionar blá para blá / ou apenas servir a mesma resposta para ambos. Este é o incrível !!! caminho. Tanta tecnologia. Quem iria querer simplesmente concatenar as seqüências de caminho quando pudéssemos fazer tudo isso?