The id property in the serialized response is currently emitted at the very end of the message. There is nothing inherently wrong with this, and it's definitely in spec. However, it means that the other end cannot easily apply certain optimizations, including
starting to process partial responses before the entire response has been received, and
skipping (parsing of) large responses whose contents they are not interested in.
Such optimizations perhaps aren't important for a majority of messages and may not be without drawbacks. However, if there's nothing speaking against moving the id it would be a (small) win.
For what it's worth, this is also the order found in the spec examples. Not that it matters much but it definitely wouldn't be an unusual thing to do.
For consistency perhaps it would be good to move the id to the front of requests as well, as opposed to responses. It would enable the other end to respond to a partial request early.
The
idproperty in the serialized response is currently emitted at the very end of the message. There is nothing inherently wrong with this, and it's definitely in spec. However, it means that the other end cannot easily apply certain optimizations, includingSuch optimizations perhaps aren't important for a majority of messages and may not be without drawbacks. However, if there's nothing speaking against moving the id it would be a (small) win.
For what it's worth, this is also the order found in the spec examples. Not that it matters much but it definitely wouldn't be an unusual thing to do.
For consistency perhaps it would be good to move the id to the front of requests as well, as opposed to responses. It would enable the other end to respond to a partial request early.