From REST in Practice: Hypermedia and Systems Architecture:
The current state of a resource is a combination of:
- The values of information items belonging to that resource
- Links to related resources
- Links that represent a transition to a possible future state of the current resource
- The results of evaluating any business rules that relate the resource to other local resources
a) why would "links to related resources" also represent the current state of a resource?
b) I also don't quite understand why "Links that represent a transition to a possible future state of the current resource" also represent the the current state.
Namely, those links represent the possibility, not the current state. Analogy would be an int variable set to value 10. It's possible that in the future this variable will get processed and set to value 100, but we don't claim its current state also includes possible future state of 100?!
links to related resources: imagine a "chat_room" resource. The links to people in that room will change as they come and go. In other words, a resource's relationships to other resources may change.
a) I also began learning domain driven design and there an entity E may have child entities ( thus E is a parent in a relationship ) and E's relationship with its child entities may change ( ie some child entities may be assigned to different parent or may get deleted).
But even though E has one-to-many relationship with its child entities, we don't consider that relationship as also representing the current state of E. That's is why I'm puzzled as to why in REST the links to related resources also represent the current state?!
imagine a university has a "student" resource. There might be a link to "register" in a class, a link to "apply for housing", and links to "tune in", "turn on" and "drop out". Each link may change the state of the object, or may yield appropriate information for the resource state. For example, the correct Student Housing application for that student.
It sort of makes sense that the state of current resource also constitute those links to related resources, which may state change the state of the current resource. But it doesn't make sense that the state of the current resource also constitute links to those related resources which don't change the state of the current resource?!
But the resource may be a sort of state machine. So a "car" resource might have links to "start_engine" if it's stopped. It might links to "speed_up", "slow_down", and if the speed is slow enough, "stop_engine". In other words, links to transition to other valid states based on the current state.
links to transition to other valid states based on the current state.
I assume you've made a typo and what you meant to write is "links to transition to other valid states is based on the current state"?
b) So could we say the reason why links that represent transitions to other states also represent current state of a resource is because every resource with such links could be considered a state machine, and with state machine, links to other valid states do represent current state ( I hope my ramblings make some sense )?!
But it seems more natural in handling structured data to just bundle the "chat_room" and "chat_room_person" information together.
I assume technically, related resources themselves don't represent the current state of a resource. Instead, only links to these related resources represent the current state of a resource?!
In REST, the goal is to eliminate all out-of-band communication. So we supplement the state (ON) with links that represent all the valid transitions for that state. So we want to avoid more documentation. The resource representation can tell us, "This is where I am, and this is where I can go next."
In REST the links that represent transitions to other states also represent the current state of a resource, but could we argue that logically ( thus not in the context of REST ) these links don't really represent the current state of a resource, and thus only reason why in REST they do represent the current state of a resource is because REST is build around that assumption ( or is at least more efficient that way )?