I would say that may bring the default closer to what is more convenient for the developer.
I’m currently implementing a bunch of examples to connect a clinical application’s backend to our current REST implementation (which is pretty out of date tbh) and when I put myself into the position of the developer who’ll use my code as a starting point; I can see that the most convenient thing would be to have whatever composition he/she POST’ed to the endpoint returned as the payload of the response.
That’s what’d feel more natural to me, because in the happy path/scenario, I’ll push a composition and get back one with a uid value in the composition payload, which I can then use or throw away.
It’s not only about the uid value (which’ll be in the location header as well) I have a habit of trying to switch to persisted representation of clinical data as early as possible in the code. So if I need to push something to CDR and then use it for any purpose, I’d rather use the persisted version than the one I sent over the wire, because if anything went wrong (I forgot to map an optional data item to the composition dto etc), using the persisted version will break my tests and I’ll know about it.
Yes, I can still make another req and get the persisted version but having it around in the body of 201 is more convenient. I appreciate this is highly subjective, and I may be violating some REST principal but from a productivity point of view, I find this to be a pragmatic approach.
This is highly subjective, so I won’t get into a discussion to defend it, but I wanted to make the point that there is at least one member of SEC who thinks it’d help to have the default returning the full representation