Although you say it's not what you need. Your question DOES suggest not creating a web service at all but to use a reverse proxy on their webservice. Any access will go through your reverse proxy which you could redirect at will.
Alternatively you could do some basic enveloping of their responses, wrap their XML or JSON in your own. You would not need to look at the XML or JSON at all or be effected by changes in it's schema.
On the other hand, if you were to switch to a different partner service. Do you think their data will look exactly the same? Would your clients be able to work with it without modification?
You could use your 'wrapper' service as a facade to make sure the data provided complies to your defined structure. In such a setup you would not automatically let through whatever field a partner may add. Your webservice would make a partners webservice comply to a certain contract. Basically protecting the client programs from unexpected changes.
Of course you could add a little pockets of key-value pairs here and there if it makes sense (the data being dynamic). Don't need a dynamic programming language for that.
Edited to address question updates, previous answer removed
Looking over your changes to your question I think I understand the problem you are facing a bit more. As there is no field that is an identifier on your resources (just a link) you have no way to refer to that specific resource within your GUI (i.e. a link to a page describing a specific pet).
The first thing to determine is if a pet ever makes sense without an owner. If we can have a pet without any owner then I would say we need some sort of unique property on the pet that we can use to refer to it. I do not believe this would violate not exposing the ID directly as the actual resource ID would still be tucked away in a link that the REST client wouldn't parse. With that in mind our pet resource may look like:
<Entity type="Pet">
<Link rel="self" href="http://example.com/pets/1" />
<Link rel="owner" href="http://example.com/people/1" />
<UniqueName>Spot</UniqueName>
</Entity>
We can now update the name of that pet from Spot to Fido without having to mess with any actually resource IDs throughout the application. Likewise we can refer to that pet in our GUI with something like:
http://example.com/GUI/pets/Spot
If the pet does not make any sense without an owner (or pets are not allowed in the system without an owner) then we can use the owner as part of the "identity" of the pet in the system:
http://example.com/GUI/owners/John/pets/1 (first pet in the list for John)
One small note, if both Pets and People can exist separate of each-other I would not make the entry point for the API the "People" resource. Instead I would create a more generic resource that would contain a link to People and Pets. It could return a resource that looks like:
<Entity type="ResourceList">
<Link rel="people" href="http://example.com/api/people" />
<Link rel="pets" href="http://example.com/api/pets" />
</Entity>
So by only knowing the first entry point into the API and not processing any of the URLs to figure out system identifiers we can do something like this:
User logs into the application. The REST client accesses the entire list of people resources available which may look like:
<Entity type="Person">
<Link rel="self" href="http://example.com/api/people/1" />
<Pets>
<Link rel="pet" href="http://example.com/api/pets/1" />
<Link rel="pet" href="http://example.com/api/pets/2" />
</Pets>
<UniqueName>John</UniqueName>
</Entity>
<Entity type="Person">
<Link rel="self" href="http://example.com/api/people/2" />
<Pets>
<Link rel="pet" href="http://example.com/api/pets/3" />
</Pets>
<UniqueName>Jane</UniqueName>
</Entity>
The GUI would loop through each resource and print out a list item for each person using the UniqueName as the "id":
<a href="http://example.com/gui/people/1">John</a>
<a href="http://example.com/gui/people/2">Jane</a>
While doing this it could also process each link that it finds with a rel of "pet" and get the pet resource such as:
<Entity type="Pet">
<Link rel="self" href="http://example.com/api/pets/1" />
<Link rel="owner" href="http://example.com/api/people/1" />
<UniqueName>Spot</UniqueName>
</Entity>
Using this it can print a link such as:
<!-- Assumes that a pet can exist without an owner -->
<a href="http://example.com/gui/pets/Spot">Spot</a>
or
<!-- Assumes that a pet MUST have an owner -->
<a href="http://example.com/gui/people/John/pets/Spot">Spot</a>
If we go with the first link and assume that our entry resource has a link with a relation of "pets" the control flow would go something like this in the GUI:
- Page is opened and the pet Spot is requested.
- Load the list of resources from the API entry point.
- Load the resource that is related with the term "pets".
- Look through each resource from the "pets" response and find one that matches Spot.
- Display the information for spot.
Using the second link would be a similar chain of events with the exception being that People is the entry point to the API and we would first get a list of all people in the system, find the one that matches, then find all pets that belong to that person (using the rel tag again) and find the one that is named Spot so we can display the specific information related to it.
Best Answer
Yes, of course
I think you are confusing a couple different ideas.
From Gregor Hohpe
So the first thing to notice in your system is that the effect on the receiver of sending the same message twice is the same as sending it exactly once.
The advantage being that it is safe for the sender to repeat the message as many times as necessary to receive an ack.
Now, in your example, you seem to be expecting something beyond that, which is that the repeated message generates the same response. That's an awesome property for your system to have, but it requires a bit more work.
The basic plot is that your server receives the duplicated message, and checks to see if it has already been handled. A naive approach would be to look at the version, and check if the change applied in this version has already been applied.
Specifically, the server gets the second message, sees that it's already on version 2, sees that the name is currently equal to "Person X", and returns success!
It's not such a great answer if somebody else slips in another change between the duplicate messages.
A real implementation is more complicated - the basic form of it is to keep track of the responses you send, and when you get a duplicate message, you send back the same response that you sent before. Udi Dahan covers this approach. The persistence of the responses is in the domain model, so the messaging is still stateless, which satisfies the REST constraint.