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.
(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:
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)