We are designing some resource oriented web services.

Service B needs to be able to make calls to Service A passing in a reference to a resource in service B that service A will use when formulating it's response. Maybe service A already has some knowledge about service B's resource from a previous interaction.


GET http://serviceA.com/resource/123?widget=http://serviceB.com/widget/456

(obviously the query parameter 'widget' would need to be appropriately encoded)

I see very few examples of this kind of thing in practice. You sometimes see it on the web e.g. an example would be redirect URIs in Google OAuth (https://developers.google.com/identity/protocols/OAuth2WebServer#formingtheurl)

It seems like it's more common to build in some knowledge of service B's resources into service A so you would instead make a call like:

GET http://serviceA.com/resource/123?widget=456

This this seems to break resource oriented design principles.

Is embedding URLs as query parameters an appropriate design approach or are there issues with it?

Clearly it could lead to issues with URL length with any user agents that have limitations on URL length. And it looks kind of ugly. But other than are there other downsides? Why isn't it used more? Or maybe it is? Is it because most REST based API designs are not truly RESTful (resource oriented) - which isn't to say they are bad either (http://www.intridea.com/blog/2010/4/29/rest-isnt-what-you-think-it-is)

closed as primarily opinion-based by Robert Harvey, Kilian Foth, Ampt, jwenting, GlenH7 Apr 25 '15 at 23:21

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    What do you mean by "bad?" Google uses this technique for their search engine to track URL clicks, so it's not exactly an unprecedented practice. – Robert Harvey Apr 22 '15 at 20:52
  • Changed title and added to my question to clarify the intent of my question. – Martin Bayly Apr 22 '15 at 22:02

This, to my mind, depends on the way you use the URL parameters. Passing URLs as actual data you have to manipulate is fine.

Imagine a REST service to handle Web bookmarks. Let's assume it associates some metadata with bookmarks (e.g. date added, icon, etc). By the REST canon a request that asks for such data for a particular bookmark will be a GET request and will have to pass the bookmark's URL as parameter.

On the other hand, it's probably not a good idea to use URL-carrying parameters to control other aspects. E.g. I can't expect to see something like &redirect=http://... among parameters of a well-designed REST API. (Please note that OAuth is not a REST API at all.)


This seems to me to be a straightforward case of the Granovetter introduction operator as applied by the client in a request - the resource receiving the request needs no prior knowledge of the specific external resource referenced (only that it have compatible behavior), and so long as the external resource being referenced is treated as a subject or object of the request you haven't departed from RESTful style.

Granovetter diagram

Here Alice is the client, Bob is the resource receiving the request, and Carol is the external resource referenced in the request. Bob has no prior specific knowledge of Carol as evidenced by the lack of an edge connecting them. foo is simply the default metasyntactic variable for an arbitrary message.

Not the answer you're looking for? Browse other questions tagged or ask your own question.