Several concepts related to REST conflict in my head when I try implementing it.
I have a REST-ful back-end API system that holds the business logic, and a web application that provides the UI. From various resources about REST (particularly, REST in Practice: Hypermedia and Systems Architecture) I know that I should not expose raw identifiers of my entities, but rather return hyperlinks with
Consider the example. The REST api has a resource that returns a person:
<Person> <Links> <Link rel="self" href="http://my.rest.api/api/person/1234"/> </Links> <Pets> <Link rel="pet" href="http://my.rest.api/api/pet/678"/> </Pets> </Person>
The problem arises with the web application. Let's assume it returns a page that contains a hyperlink to browsers:
<body class="person"> <p> <a href="http://my.web.app/pet/???????" /> </p> </body>
What should I put into the
href attribute? How do I keep the API entity URL in the web application to be able to get the entity when a user opens the target page?
The requirements seem conflicting:
- The hyperlink
hrefshould lead to the web application because it is the system hosting the UI
hrefshould have some id of the entity because the web app must be able to address the entity when the target page opens
- The web app should not parse/construct REST URLs beacuse it's not REST-ful, The mentioned book says
URIs should be opaque to consumers. Only the issuer of the URI knows how to interpret it and map it to a resource.
So, I cannot just take
1234 from the API response URL because as a RESTful client I should treat it as if it was something like
http://my.rest.api/api/AGRIDd~ryPQZ^$RjEL0j. On the other hand, I must give some URL that leads to my web app and is enough for the app to somehow restore the API's original URL and use that URL to access the API resources.
The simplest way is probably just using the API URLs of resources as their string identifiers. But web page urls like
http://my.web.app/person/http%3A%2F%2Fmy.rest.api%2Fapi%2Fperson%2F1234 are ugly.
With a web app I can imagine several approaches, but all seem weird:
- Replace the host in the API URLs and keep the result only. The huge downside is that it requires the web application to handle whatever URL the API generates, meaning monstrous coupling. Moreover, it's not RESTful again, because my web app starts interpreting the URLs.
- Expose the raw ids in the REST API together with the links, use them to build Web App's URLs, and then use the ids on the web app server to find the required resources in the API. This is better, but will affect the web app server performance because the web app will have to go through the REST service navigation issuing a chain of get-by-id requests of some form to handle any request from a browser. For a somewhat nested resource this might be costly.
- Store all
selfURLs returned by the api in a persistent (DB?) mapping on the web app server. Generate some ids for them, use the ids to build the web app page URLs and to get the URLs of the REST service resources. I.e. I keep the
http://my.rest.api/pet/678URL somewhere with a new key, say
3, and generate the web page URL as
http://my.web.app/pet/3. This looks like a HTTP Cache implementation of some sort. I don't know why, but it seems weird to me.
Or Does it all mean that RESTful APIs cannot serve as backends for web applications?