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.
If you want to communicate state between two participants in a game, one relatively simple way to do it would be to have a web service which allows each player to PUT the resource that represents the shared game state, with verification to make sure that they don't make illegal moves (or modify the other player's moves). This is an example of the logical flow:
- Assign each player a token, after they've authenticated (using an email, for example).
- Allow a player to invite another to play a game. This could take the form of sending a message to the other player, to which the other player could respond.
- If the invitee accepts, create a shared resource to which those two users have permissions, and communicate the URL to both player resources.
- Allow the web app to PUT representations of the game state to the shared resource. In the case of chess, a simple example would be to have a shared PGN file to which both users could write.
If you're interested in this approach, which would be an example of "SOA," or "service-oriented architecture," you might try SOA with REST or RESTful Web Services. This architecture is server-client oriented, not peer-to-peer; that has the advantage of being much simpler to implement.
You could implement your web services as separate routes within your Django project, and have AJAX calls from your Javascript front end which actually perform the actions related to the game state. I think Unity would be overkill for what you're trying to do; it's more about graphical games.
Best Answer
In the past I have approached problems like this by minimizing latency either on the client side or on the server side. Knowing the size of the network pipe is one thing, but it usually something that you cannot modify. Usually, with a centralized server, it is the server that is the issue.
Although quite a bit is left to judgement, there are some approximations.
So consider what basic steps you web app has to do and tally the up. See how close you are - either you have forgotten something ( most likely), or you need to modify your approximations.
For example, there was a web application that I was working on that most requests took a bit more than 70 ms to respond. I traced this to 7 database operations. A Proposal to increase performance was to cache more data locally (we were hitting a couple of static tables that could be cached locally), bringing the latency down to bit more than 50 ms. Furthermore, by going with SSDs, we could potentially bring it down a bit more 5 ms. Of, course lower latency means that the server can handle a higher peak load.