Allowed responses are pre-defined in REST. If you submit a "create" or an "update", the FHIR spec defines what resource can come back and no implementation decision is needed. With messaging, there's a need to define what event codes and Bundle content the response message can contain - so there's much more negotiation required. For example, if doing a create Patient in REST, what the URL needs to look like is defined. The payload on the way in must be a Patient resource and the payload on the way back must be Patient (with defined headers allowing you to say if you want the patient back or not) With messaging, you'd need to define an event code for "create patient". You'd need to decide if the message bundle included only Patient or if it also included RelatedPatient, Coverage, AllergyIntolerance and other information (as is done in the v2 equivalent). You'd also need to define whether the response message would be a simple "ack", would echo back just the patient with identifiers, the full patient or all persisted resources.