Search code examples
restasp.net-web-apihateoas

HATEOAS For a Browser-Based Client Consuming a RESTful Web API


I am currently designing a RESTful API in ASP.NET, and will also be designing 1 browser-based client that will consume this RESTful API (also using ASP.NET). For now, I would like both the client and API to be serviced from the same solution.

A concept that I am having difficulty wrapping my head around is how I can have a logical separation between the client and API without compromising the synchronization of the client page mappings with the data (from the API) that is displayed in those pages. From the fundamental nature of a browser-based application, it is served in a RESTful manner; the discovery of additional client pages is via a single entry-point and HATEOAS. Also, with the RESTful API, resources (application data) are discovered at runtime via a single entry-point and HATEOAS.

For me, this concept translates as follows:

For the client:

Welcome Page (My client entry-point): www.example.com/home

Within the HTML of this page, I have links to:

www.example.com/profilePage
www.example.com/contactsPage

etc...

For the API:

Entry Point:

www.api.example.com

My JSON result (or other media type response) contains links to the following:

www.api.example.com/resourceToBeDisplayedOnProfilePage
www.api.example.com/resourceToBeDisplayedOnContactsPage

Am I correct so far in this understanding? How can I have the client know how to get the data for the respective screen when the links in each page's HTML are purely for pages?

(My motivation for this separation are for scalability and performance purposes. It would be nice to be able to cache the layout, styling, and scripting for the client application pages without context on the data that is being displayed by those pages. I expect that the stagnancy of the page layouts will be far greater than the data that can be displayed within those pages, therefore allowing me to cache the pages for a far greater amount of time.)

Also, given my explanation of my understanding, can you see any additional aspects of REST that I may potentially be failing to consider in my design, or am just downright wrong?


Solution

  • I think you need to use XHTML as media type instead of JSON and will help you working with link.

    You can follow this link Session: Hypermedia APIs where Jon Moore described the use of XHTML as media type instead of JSON.