>
>
> I had to think about it for a while, but I'm +1 for this approach with
> generically definable {context}/{identifier}. A minor comment is that when
> we talk about delivering a a full renderable page with all associated data
> - context, authenticated user, widget render & metadata - I feel like we
> are breaking from rest. Is that true? In that case would it make more sense
> to put these routes not under the api? Under this model...
>
I don't think it breaks rest. It is still a representation of the resource.
>
> /api/... restful api that delivers resources
> /{context}/{identifier}/pages - application routes. With accept headers of
> html, delivers the html page with bootstrapped data. with accept headers of
> json, delivers just the json data representation.
>
>
I can see where you are going with this, but I would like this capability
in "core" and think view matching & other MVC pieces are part of an
implementation, like the OOTB portal. I would be ok with a separate
contexts API though that delivers the rendered pages.
Sot that we are not totally talking in abstract, I have committed enough of
the pieces for us to look at the render-ready/export-ready versions of the
pages. Paths are by no means "correct" or final:
Some examples of current functionality:
/api/rest/pages/{pageId} Returns the export
version of the page with the specified id
/api/rest/pages/portal/@self Returns all portal pages
for the currently authenticated principal (user)
/api/rest/pages/portal/@self/{pageId} Returns the portal page with
the Id of pageId for the currently authenticated principal (user)
/api/rest/pages/portal/{userId} Returns all portal pages
for the userId
/api/rest/pages/profile/{userId} Returns all profile pages
for the userId
