Aplicando o design RESTful a um site inteiro?

Tudo isso pode parecer muito novato, mas estou tentando entender o design de um site totalmente RESTful. Entendo aplicar o design RESTful a coisas como usuários, fotos, postagens de blog etc. porque penso neles como "objetos".

Mas, que tal uma página "sobre nós". Que tipo de recurso é esse? É mesmo um recurso no sentido RESTful da palavra? Além disso, digamos que eu vá para o URL "http://www.example.com/", que recurso estou solicitando? O recurso de índice?

O padrão de recurso do site RESTful mais comum que vejo é adicionar uma exibição ao URI:

/ resourcetype / identifier [/ view ] [/ page] [? filterparams]

Quando não há exibição , basta exibir uma exibição padrão. No seu caso:

• / - uma solicitação de example.comretorna a exibição padrão do recurso de nível superior - seu site.
• / aboutus - a visualização "Sobre nós" do recurso de nível superior. Ou, alternativamente, aboutuspode ser um identificador nomeado para um recurso no escopo do CMS de nível superior. *
• / customers / 1 / aboutus - essa solicitação indica uma visualização "Sobre nós" no escopo do cliente 1 .

Dito isto, às vezes é melhor manipular um pouco a melhor semântica. Por exemplo, o StackOverflow usa o RESTful / questions / [id] para perguntas, mas a página Fazer pergunta é / questions / ask, que não é muito RESTful ( asknão é um questionsrecurso), mas faz muito sentido usar meros mortais.

^{* Nos CMSs de nível superior, o tipo de recurso é frequentemente, mas nem sempre, removido porque é redundante.}

Lembre-se de que o design RESTful em si se destina a fornecer um padrão pelo qual a Web se torna uniformemente programável. Nem sempre é apropriado ou útil colocar todo o site voltado para o ser humano na pura semântica REST.

Quando você tem recursos, considerar suas representações é útil. Também é importante considerar os outros princípios de design do REST, como statelessnes, e como eles afetam o desempenho e a usabilidade do seu site. Mas lembre-se de que o REST é uma ferramenta, não uma meta. É um meio, não um fim.

Use a semântica RESTful quando útil , depois de entender seus propósitos e benefícios, e não se preocupe se o site não estiver perfeitamente RESTful. Seria quase impossível para qualquer site não trivial em qualquer caso.

TL; DR : REST é uma ferramenta. Use-o quando e onde for útil, mas não se limite a isso.

Mas e uma página "sobre nós" [?] Que tipo de recurso é esse?

Complexo. Nada de errado com um recurso que possui componentes, peças ou estrutura.

Os recursos não são "linhas de banco de dados relacionais" ou outras coisas atômicas. Eles são recursos.

Os bancos de dados orientados a documentos lidam com isso mais facilmente porque um recurso pode ser maior e mais estruturado.

É mesmo um recurso no sentido RESTful da palavra?

Sim.

Além disso, digamos que eu vá para o URL "http://www.example.com/", que recurso estou solicitando?

Não.

Você está solicitando o recurso "aboutus". É possível (mas estranho) que um recurso seja um singleton. Sem identificação e não uma "lista".

http://www.example.com/aboutus/?format=xml

Retorna um documento XML complexo com várias partes e partes. Nada de errado com isso.

O recurso de índice?

Não significa muito no sentido "RESTful". A página "índice" é para pessoas. Um aplicativo que usa uma API RESTful foi projetado para solicitar tipos específicos de recursos.

Eu manteria minha visão independente do back-end. Você pode solicitar recursos ao back-end, como itens do acordeão, barra de navegação e outros objetos que pertencem ao corpo. No entanto, você deve deixar o processamento dessas representações de recursos no código do cliente, que as renderizará de acordo com os requisitos.

O recurso para "Sobre nós" é ... Nós :) er, você. Pense nos atributos de você que você deseja divulgar e enrole-os como um substantivo com uma representação.

Esses valores não precisam vir de um banco de dados ... provavelmente haverá um monte de valores de string, e esses podem vir de config, ou talvez até codificados em uma classe.