The beauty and power of REST is in its conceptual and syntax simplicity, ease of use for consumers, and freely available technology stack.

For example, if I have a URL that says…

https://server_name/patient/?patientName=DENNISON

…you can probably guess what will be returned without reading any documentation (answer: info on patients with the Dennison in the name). Another example…

https://server_name/study/?patientId=123&accessionNumber=456&view=epr

…would return a specific study with some form of defined application setting called “epr”.

REST is always stateless, can use any accepted authentication method used with URLs (e.g. Kerberos, OAuth, OpenID, etc.), and perhaps most importantly can be used by Web browsers (and any other consumer) without any added client technology. Other Web service methods, like SOAP, are effective for machine to machine communication (which is why they are popular in large-scale enterprises for transactions), but are not possible to consumer from a Web browser without some for of added download. IHE went heavy into SOAP due to the influence of the preferences of the large companies involved–and, to be fair, most of the integration profiles were dealing with machine to machine transactions, and SOAP was more defined/accepted than REST, at the time. Now they are rapidly turning to REST as innovators, eager to unlock the power of REST proven by companies like Google, Facebook, and Twitter, are involved in the integration profiles.