Getting the document path (HippoCMS rendered) in the REST API detail

Hi there,

Is there a way to get the path (URL) of a document in the Content REST API Document Detail JSON response?

I’m looking for the path/URL of the html document served/rendered by HippoCMS (e.g. http://localhost:8080/site/path/to/document.html), not the API url (e.g. http://localhost:8080/site/api/documents/{uuid})


I have a site built in and rendered by HippoCMS. There are existing “product” documents, with the document type containing attributes like “title”, “description”, “price” and an image. These pages can be browsed to and viewed in the site served by Hippo.

I have another site, built on a completely different platform, where I want to included the contents of one the “product” documents. I have set up the Content REST API in Hippo CMS and can get a list of my “product” documents using http://localhost:8080/site/api/documents/?_nodetype=mysite:product. From this I select one document and get the contents of the document using http://localhost:8080/site/api/documents/{uuid}. The title, description, price and image is rendered as a banner on a page of the other site using a JavaScript template library. Up to this point everything works great.

What I however need is a link back to the original document page served on the HippoCMS site, which the end used will view for more info. All I have available is the uuid of the document. Is there a way to get the path/URL of the page?

Checkout the

org.hippoecm.hst.core.linking.HstLinkCreator#create(java.lang.String, javax.jcr.Session, org.hippoecm.hst.core.request.HstRequestContext)

(first arg is uuid)
you can get the link creator from the request context like:

1 Like

Thanks for your response. I’m not sure however how to get this into the document detail JSON output of the Content REST API. Is this documented anywhere where you can link me to?

You can’t directly influence what the content rest api does, for that you will have to write your own rest service[1].

What the content rest api does is give you a json representation of your content. What you could do is add a link field to the document tyepe and then explicitly link to the same document. This will get you the link in the content rest api.



HI Andre,

I would suggest to implement Content/Context aware jaxRS component [1]. That component needs to use an object mapper to convert your document to the equivalent JSON representation.

Moreover in that JSON object you can include the link generated by HST as suggested by Baris.




Ops, since the only information available to you is the document uuid, then my suggestion about using the content/context aware is wrong.

Please consider to use plain RESTful JaxRS [1].



1 Like

Thanks for the replies everyone. I have reviewed the links provided and attempted to implement it. While the configuration of the services were easy, unfortunately Java development is outside of my area of expertise.

This seems like a reasonable alternative, but I have a follow up question. Since we already have hundreds of product documents already in the system and I would also not necessarily want the product loaders to have to manually add a link (as a string to prevent Link rewriting to an api link) when adding a product (error prone) , is there a way to add the link (string) field to the document type with it’s default value set as a path for itself, and hide it from the document editing view or make it read-only ?

You can’t set a default value pointing to the document itself afaik. What you can do is run a groovy updater to update all current documents. If you also add an event listener or derived data function to set the self reference. You can hide it from editors by removing the configuration for that property under the editor:templates.

1 Like

I’ve managed to implement responding to a workflow event, at which time I write a value to the pageUrl property I’ve added to the document type. This value is also now passed in the api JSON response.

What I’m still not managing to get right is getting the page URL, which is what I want to write as the value for the property.

I have at the time I’m responding to the workflow event available to me either the String uuid or the Node node, which I can use as first parameter to HstLinkCreator.create(). What I’m missing is the other parameters. It seems I have to look at either HstRequestContext requestContext or Mount mount.

Since I’m now trying to get the URL at the time of saving the document in the CMS, which should be the preferred parameter and how do I get an object for it? Neither seems to provide a “get current” method.

You need valid request for that, so, you are pretty much out of luck. Your best bet is to have some REST service which would return you the link for given UUID

1 Like

There is no request context when you are responding to the workflow event. So you cannot use the HstLinkCreator unless you implement a jaxrsrestplainpipeline [1]. But if you are following the path that jasper suggested, then all you have to do is adding a node under the node you are working on (mirroring the internal link field in the cms). That node is something like:

  jcr:primaryType: hippo:mirror
  hippo:docbase: uuid_of_the_document_goes_here


1 Like

If I use hippo:mirror, the link that gets added to the JSON output is being rewritten from a site URL to an API URL by the Content REST API.

Is there a way to prevent this? I need the site URL, which is why I was after a string value instead of mirror. (i.e http://localhost:8080/site/path/to/document.html, not http://localhost:8080/site/api/documents/{uuid})

I understand. It really seems like you have no option other than write a plain jax-rs service yourself so you can use the HstLinkCreator.

1 Like

Thanks, I’ll get our Java developers involved to look at that.

Just a last idea; is there any URL pattern (out-of-the-box) that allows browsing to a site page using the UUID, even if the link isn’t pretty? Something like:


Not the site pages, AFAIK. There’s content hal api which takes a uuid as path param, but that also has the “api url” like you mentioned above.

1 Like

One correction: If you configure the parent mount (e.g, hst:root) of the Content HAL API mount (e.g, hst:root/api) with hst:alias [1] by setting it to site, then Content HAL API will include “site” link as well automatically like the following example:

  "_links": {
    "self": { "href": "http://localhost:8080/site/api/documents/18e36c35-429d-4fee-b76e-eeabcbfc08bb" },
    "site": { "href": "http://localhost:8080/site/events/2019/01/introduction-speech.html" }

The installation steps [2] include a setting, hst:mountsite: site, which makes the relationship with the mount having hst:alias: site.

I’ll try to improve the documentation (installation and examples) to cover this later.



1 Like

This looks promising.

Is this only available for Enterprise customers in the Content HAL API [1], and not in the open source Content REST API [2]?

The link output looks similar to the Page Model API (SPA) [3] examples I have looked at as an alternative solution.


It’s available only for Enterprise customers now. Hmm…

Yeah, in links, I copied it from Content HAL API to Page Model API. :smiley:
Of course, by its name, Page Model API serves for different purposes: not just content models but also HST page/component structure. Content HAL API is focused only on Content-as-a-Service style API provision.



1 Like

After some more reading of the various documentation I realized I can use the Content REST API alongside a custom Plain JAX-RS service. I was worried that writing a custom Plain JAX-RS service would mean that all the useful functionality provided by the Content REST API will have to be rewritten in the custom implementation, since I need that search functionality too. I now realize that this was probably what was meant by many of everyone’s suggestions already.

So I created an endpoint that takes the UUID as a path parameter and using the HstLinkCreator as suggested, returns the URL. While this would mean making two REST calls from the client, one for the link and one for the document content, this is acceptable and I’m happy to say that this resolves my problem.

Thanks everyone for all your suggestions and help, as well as all your patience.

1 Like

Was there some way out documentation could’ve been clearer to help you reach a solution earlier?

Anyway, good to hear you found a solution. Thanks for letting us know.