decoupled (but cool) urls in a hypermedia client

[Ricardo Kirkner]

Hi again,

this time I come with a question on keeping urls decoupled between client and server.

tl;dr how can I keep urls in the client and the server decoupled without losing information.

@context

Let's say I have an hypermedia API serving hal+json responses, and I have a web app as the client.

Since I want to make sure I'm not depending on any server side urls implicitly, I have a completely different url namespace on the client than on the server (eg, /app/<name> on the client and /applications/<id> on the server)

@problem

if I just keep the server links in the html I serve to the users, they will get sent to the server (api) urls, breaking out of the web app; this suggests I need to replace the api links with client-side versions of them and have a handler on the client that knows how to map them to server urls in order to fetch the data.

are there any common patterns / best practices for this, that are not really ugly (like passing the server url as part of the client url)?

thanks,
Ricardo

[javier hector]

Hi Ricardo,

Not sure if it's helps but for me the server need to tell the client all the urls that he need to use.

Thus, the client does not depend on URL construction or their structure.

/Javier

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[Ricardo Kirkner]

Hi Javier,

yes, I agree the client should use the urls the server gives it, and not construct them manually... however, that is for urls for accessing resources on the server. Here I'm talking about urls for the client itself (remember this client is itself a web app, so it has it's own url namespace).

[Jørn Wildt]

I heard a similar discussion yesterday. It is really odd to talk about *client* URLs? Is it something Angular specific?

/Jørn

[Ricardo Kirkner]

Hi Jørn,

not using Angular here at all ... so I'd say no :)

I think this is probably common with web-based clients that consume json and render their own html... if you'd include the links the server provides as they are, when a user clicks on one of those, it would get json and not a nicely rendered html  page.

[Darrel Miller]

Ricardo,

Having one web app call a hypermedia web api when both pieces are
under your control and both trying to achieve the same goal is going
feel a bit weird. Using hypermedia to enable decoupling requires a
certain amount of overhead that is probably going to feel like
overkill when you control both ends of the wire.

As an aside, do you really need your web app to talk to your web api?
Could both products not share some other implementation component that
would avoid making that extra HTTP request within your own data
center?

Assuming you do have a good reason to add the extra layer, I see you
as having two choices:

a) Don't try and create any correlation between the two sets of
resources Build the hypermedia in the web app as if you were not
talking to a web api at all. Then consume your Web API to generate
the content for the web app. However, I suspect this approach is going
to feel very redundant.

b) Create a portion of the URI space in your web application that is a
function of of the Web API URI path. e.g. If you want to build a
resource that renders in HTML some content from content in your Web
API, then define something like

http://webapp.example.org/appviews/{apipath}

If your api uses query parameters, then you are going have to find a
process of merging query parameters from the api with query parameters
from the web app. You might just combine them and ensure that you
avoid duplicate names.


Darrel

On Fri, Apr 4, 2014 at 10:41 AM, Ricardo Kirkner