My question explains best with a little example.
Let's assume we are building a simple web application to monitor train journeys in real-time. Every time when a train stops at a railway station, the current location of the train is manually logged by the driver of the train.
There is one resource called /journeys and one called /drivers. In this example, the driver is responsible to manage a specific journey. The train driver creates a journey with a POST request to the /journeys resource. He gets back a journey with id 15. The driver needs to update the resource /journeys/15 multiple times in order to log every stop at a railway station.
The relationship between resource journeys and resource drivers (journeys -> drivers) is kept until the journey of a train finally ends. That is when the train reaches it's destination. After that, the information about the journey is kept for further analytics. At this part, the information about who was the driver is not important anymore.
Now to my question: Depending on the state of a specific journey, there are two slightly different representations of the resource with id 15. One with a relationship journeys -> drivers and one without any relationship. Should a resource design like this be avoided or is such a design common practice? In my opinion, such a design could maybe lead to confusion.
Would it be better in this example to have two seperate resources, such as /live/journeys and /analytics/journeys to avoid confusion and to seperate live application state and business-view state?
Should a resource design like this be avoided or is such a design common practice?
It's fine.
Imagine the "resource" as a web page. GET /journeys/15 returns a document that is an HTML representation of the journey. As the driver reports events, the document updates to match. The "end of journey" event removes the information about the driver that is enclosed within the document.
That's all perfectly normal.
Human beings are decent at dealing with that ambiguity, but for machines we probably want to have a more explicit schema. For this design, that would include a description of how to interpret the document to extract various bits of information, and which elements of information are optional.
Would it be better in this example to have two seperate resources, such as /live/journeys and /analytics/journeys to avoid confusion and to seperate live application state and business-view state?
Let's start with "is it reasonable?" Yes. Resource models might have many resources with common information. As an analogy, you might consider two different reports produced by queries on the same data set. Having different resources for each report is a perfectly normal design.
Is it better? "It depends". The potential problem with having multiple resources describing the same information is that cached copies of the two resources may not be synchronized. General purpose components (like web caches) won't necessarily know that the resources are related, and in particular won't know all of the resources that need to be invalidated when the driver updates /journeys/15
For a domain where nobody is likely to look at the analytics resource until the journey is done, synchronization probably isn't a big concern, so multiple resources should be fine.