What are we after, exactly? We're trying to find ways in which we can avoid duplication of effort when using both Object Relational Mappers and RESTful Web Services. In their book "RESTful Web Services", Richardson and Ruby hit on the point that the process of translating objects into REST resources is very similar to the process of translating the same objects into tables in a relational database. So, if a web service is storing objects in a database and exposing them via a rest api, we would be doing the same sort of mapping procedure twice.
My partner (in crime?) and I had a chat with Greg about this, and came up with some questions to investigate. Below are the questions and their answers:
How do REST APIs represent foreign-key relationships (ie. object aggregation)? Specifically, are references to the other objects stored/returned, or the entire object on each request?
- It is common REST practice to return hyperlinks to other objects/resources that are aggregated by the given resource. This would require an additional http request for each referenced resource.
- Yes. The resource's URI is its identifier. Every resource has one that identifies it. However, it is possible for one resource to have many URIs that point to it (ex. /releases/2_05 and /releases/latest could be the same thing).
- Yes. It would be silly not to. However, the multi-identifier problem stated in the last answer might make this less efficient.
- I think so.
2 comments:
Why do you think the object graph will "probably" be acyclic?
Now that I think about it, the graph will almost certainly be cyclic, if the REST service implements bi-directional relationships in the same way SQLAlchemy does. That is, if there is a bi-directional relationship between classes A and B, then class A contains a reference (member) to class B, and class B contains a reference to class A. Cycles.
Post a Comment