uri strategy & content negotiation

We have a growing demand of uri's to identify things (cataloguerecords, distributions, locations, users, groups, maps) in geonetwork. The demand comes from search engines sitemap.xml, but also share on twitter/facebook/linkedin should reference a serverside generated html of a record, so the exteral engine is able to parse the html and extract keywords/title/thumbnail using schema.org and/or og vocab. Another interest comes from (linked) open data, in the conversion from iso19139 to dcat it is a good practice to define uri's for objects (else they are blank nodes). Those uri's can then be used to reference subsections of metadata.

Uri's are kept persistant over time and resolve to sensible representations of things, preferably supporting content negotiation.

With the introduction of the api we have started migrating services from the old /srv/{lang}/method to /api/{version}/method. Both url's however are not very persistent and unique to be used to identify things in the application.

In stead I suggest to use a serverside rewrite that rewrites a designed uri of a thing to an api method that retrieves the thing using the latest version, eg. /id/record/112233 to /api/v2/records/112233. Content negotiation will determine what encoding will be served, either html, iso-xml, rdf-xml, atom/rss-xml, json-ld. content negotiation can be implemented in the rewrite rule or in spring-mvc.

A general challenge with designing uri's and serverside rewrites in the html output is that when you reference images/css/scripts relatively, the uri should have the same level of nesting as the url to which you are forwarding.

Related to multinode, i would like to discuss with you if there is shared interest to extend how the relevant node is inserted in the uri. And if we see alternatives for introducing it in the uri. Can we implement nodes for example as http://{node}.{domain}/api/{v}/records.

From a search engine prespective the current formatter framework is optimal, having cached html representations on disk gives instant response from search results (search engines measure response time and use it in ranking). The formatter framework can be used to provide the html representation of a record? To facilitate a similar UI experience as part of the formatter and the angular UI, we introduced skinning capabilities in the xsl header/footer. But I can even imagine we remove this part from angular and use it only from xsl (or spring-mvc/jsp)