Consensus has been reached to pursue the operations extension proposal. We would like to have a single recommended path for multi-operation support, and the operations extension has proven to be the most flexible. It supports all the use cases thus far, including streaming.
Further work needed:
How to parallelize requests? Suggestion: servers can look to usage of pointer references to determine when it’s feasible.
Mappings for all possible query params to attributes of an operation.
How to allow for greater response customizability (e.g. different fields used for resources of the same type, depending on their relationships)? This could be achieved using multiple fetch requests.
How to truncate or eliminate response payloads for certain operations?
Extension negotiation
Extensions are the other major issue to tackle in 1.1.
@ethanresnick will review his WIP proposals from May re: extension negotiation.
Are you guys still meeting? Would it be possible to join such meetings? I would be interested in listening to your discussions (it seems that these two outstanding topics are still open) and maybe share my thoughts on the matter.
I will probably go ahead and submit a proposal for the operations. My focus will be less on the focus of the single request for performance angle, since that is mainly a problem with HTTP 1.1, but on the operations planning. I think of a plan being a blueprint of operations indicating:
How operation & operation groups can be scheduled: parallel vs sequential.
What operations need to be rolled back in case of error in an operation.
How are responses returned.
I see this outside of REST and even outside of HTTP. We can even open a socket with a server and stream operations and get responses. A proposal in these lines should not assume that a single message constitutes an operation (or a plan), but may need to wait for more information to be streamed in.
I know these are a lot of random thoughts and that’s why I’d like to hear your take on this stuff in the next meeting.