¿Aplica el diseño RESTful a un sitio web completo?

Todo esto puede parecer muy nuevo, pero estoy tratando de entender cómo diseñar un sitio web que sea RESTANTE. Entiendo que se aplica el diseño RESTful a usuarios, fotos, publicaciones de blog, etc., porque los considero como "objetos".

Pero, ¿qué pasa con una página "sobre nosotros". ¿Qué tipo de recurso es ese? ¿Es incluso un recurso en el sentido RESTful de la palabra? Además, digamos que voy a la URL "http://www.example.com/", ¿qué recurso estoy solicitando? El recurso índice?

El patrón de recursos del sitio web RESTful más común que veo es agregar una vista al URI:

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

Cuando no hay vista , simplemente sirve una vista predeterminada. En tu caso:

• / - una solicitud de example.comdevuelve la vista predeterminada para el recurso de nivel superior: su sitio web.
• / aboutus : la vista "Acerca de nosotros" del recurso de nivel superior. O, alternativamente, aboutuspodría ser un identificador con nombre para un recurso en el ámbito del CMS de nivel superior. *
• / clients / 1 / aboutus : esta solicitud indicaría una vista "Acerca de nosotros" en el ámbito del cliente 1 .

Dicho esto, a veces es mejor esquivar un poco para mejorar la semántica. Por ejemplo, StackOverflow usa RESTful / preguntas / [id] para las preguntas, pero la página Preguntar pregunta es / preguntas / preguntar que no es muy RESTful ( askno es un questionsrecurso) pero tiene mucho sentido usar simples mortales.

^{* En los CMS en el nivel superior, el tipo de recurso a menudo, pero no siempre, se elimina porque es redundante.}

Tenga en cuenta que el diseño RESTful per se pretende proporcionar un estándar por el cual la web se vuelve uniformemente programable. No siempre es apropiado o útil calzar todo su sitio web con orientación humana en una semántica REST pura.

Cuando tienes recursos, es útil considerar sus representaciones. También es importante tener en cuenta los otros principios de diseño de REST, como los sin estado, y cómo afectan el rendimiento y la usabilidad de su sitio web. Pero recuerde que REST es una herramienta, no un objetivo. Es un medio, no un fin.

Use la semántica RESTful cuando sea útil , después de comprender su propósito y beneficios, y no se preocupe si su sitio no es perfectamente RESTful. Sería casi imposible para cualquier sitio no trivial en cualquier caso.

TL; DR : REST es una herramienta. Úselo cuando y donde sea útil, pero no se limite a ello.

Pero, ¿qué pasa con una página "sobre nosotros" [?] ¿Qué tipo de recurso es ese?

Complejo. No hay nada malo con un recurso que tiene componentes, piezas o estructura.

Los recursos no son "filas de bases de datos relacionales" u otras cosas atómicas. Son recursos

Las bases de datos orientadas a documentos manejan esto con más gracia porque un recurso puede ser más grande y más estructurado.

¿Es incluso un recurso en el sentido RESTful de la palabra?

Si.

Además, digamos que voy a la URL "http://www.example.com/", ¿qué recurso estoy solicitando?

No.

Estás preguntando por el recurso "aboutus". Es posible (pero extraño) que un recurso sea un singleton. Sin ID y no una "lista".

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

Devuelve un documento XML complejo con muchas piezas y partes. Nada de malo con eso.

El recurso índice?

No significa mucho en un sentido de "DESCANSO". La página de "índice" es para personas. Una aplicación que utiliza una API RESTful está diseñada para solicitar tipos específicos de recursos.

Mantendría mi punto de vista independiente del back-end. Puede solicitar recursos al back-end, como cosas que van en el acordeón, la barra de navegación y otros objetos que pertenecen al cuerpo. Sin embargo, debe dejar el procesamiento de estas representaciones de recursos en su código de cliente, que eventualmente las representará según los requisitos.

El recurso para "Acerca de nosotros" es ... Us :) er, You. Piense en los atributos de usted que desea publicitar y enróllelos como un sustantivo con representación.

Esos valores no tienen que provenir de una base de datos ... probablemente serán un montón de valores de cadena, y esos pueden provenir de la configuración, o tal vez incluso codificados en una clase.