Anyone who implements this might want to bear in mind that you will have created a very chatty backend based on JSON calls.
It should be fairly obvious that you're quite likely to now have pain points in serialising and deserialising that much JSON.
It seems to me that you now have 2 choices:
1) You forget this approach and instead perform REST composition and aggregation by adding a datastore in the composition/aggregation service to reduce the number of calls to the back end.
2) You ditch the internal REST services and change to using protocol buffers or something else to remove the JSON bottle neck internally.
Either of which will make ql.io redundent.
ql.io appears to be trying to solve REST as the language of enterprise services, without using a service bus or BPEL to aid with composition or aggregation.
I agree there is a problem space here, and whilst I have an immense amount of respect for Subbu (worked on ql.io, authored REST book) I'm unconvinced that this approach is the solution to the problem.
It should be fairly obvious that you're quite likely to now have pain points in serialising and deserialising that much JSON.
It seems to me that you now have 2 choices:
1) You forget this approach and instead perform REST composition and aggregation by adding a datastore in the composition/aggregation service to reduce the number of calls to the back end.
2) You ditch the internal REST services and change to using protocol buffers or something else to remove the JSON bottle neck internally.
Either of which will make ql.io redundent.
ql.io appears to be trying to solve REST as the language of enterprise services, without using a service bus or BPEL to aid with composition or aggregation.
I agree there is a problem space here, and whilst I have an immense amount of respect for Subbu (worked on ql.io, authored REST book) I'm unconvinced that this approach is the solution to the problem.