HATEOAS Для клиента на основе браузера, использующего веб-API RESTful

Question

В настоящее время я разрабатываю API RESTful в ASP.NET, а также проектирую 1 браузерный клиент, который будет использовать этот RESTful API (также используя ASP.NET) , На данный момент я хотел бы, чтобы и клиент, и API обслуживались из одного и того же решения.

Концепция, с которой я столкнулся с трудностями, заключается в том, как я могу иметь логическое разделение между клиентом и API без ущерба для синхронизации сопоставлений клиентских страниц с данными (из API), которые отображаются в этих страницы. Из фундаментальной природы приложения на основе браузера оно обслуживается RESTful способом; открытие дополнительных клиентских страниц осуществляется через одну точку входа и HATEOAS. Кроме того, с помощью API RESTful ресурсы (данные приложения) обнаруживаются во время выполнения через единую точку входа и HATEOAS.

Для меня это понятие переводится следующим образом:

Для клиента:

Добро пожаловать Page (Мой клиент точки входа): www.example.com/home

В HTML из эта страница, у меня есть ссылки на:

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

и т.д ...

F или API:

Точка входа:

www.api.example.com 

Мой результат JSON (или другой медиа-ответ типа) содержит ссылки на следующие:

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

я правильно до сих пор в этом понимании? Как я могу узнать, как клиент получает данные для соответствующего экрана, когда ссылки в HTML каждой страницы предназначены исключительно для страниц?

(Мотивация для этого разделения для целей масштабируемости и производительности. Было бы неплохо иметь возможность кэшировать макет, стиль и сценарии для страниц клиентского приложения без контекста на данных, которые отображаются этими страницами Я ожидаю, что стагнация макетов страниц будет намного больше, чем данные, которые могут отображаться на этих страницах, поэтому я могу кэшировать страницы на гораздо больший промежуток времени.)

Также, учитывая мое объяснение Насколько я понимаю, вы можете увидеть какие-либо дополнительные аспекты REST, которые я могу потенциально не учитывать в своем дизайне, или просто совершенно неправильно?

Answer 1

Я думаю, вам нужно использовать XHTML как тип носителя вместо JSON и поможет вам работать со ссылкой.

Вы можете перейти по этой ссылке Session: Hypermedia APIs, где Джон Мур описал использование XHTML в качестве типа носителя вместо JSON.