Sorry, I know that this is not the list to have this discussion but the sentence
"I do think the REST architecture style is better than most SOAP, CORBA and ESB solutions" Sounds too categorical to me!! you must study case requirements deeply and you could not affirm this for every case!! States are crucial in many scenarios!! Supporting services (trading, name, time, ...) are key in complex architectures!! Indirect communication is essential in many healthcare scenarios!! REST could be the best for some situations but it is not the best in any case!! I'm agree with the other part "Doing REST properly is not easy. " As Doing any other thing in such complex use cases!! In fact doing REST properly is too much easy that doing CORBA, for example, properly..., the "easier" use of REST architecture style (versus other as SOA, Distributed objects, Agents...) is one of it positive points!! Best Regards El 19/01/2015 a las 13:10, Ralph van Etten escribi?: > Hi, > > > On 01/19/2015 11:31 AM, Birger Haarbrandt wrote: > >> The medrecord openEHR server is also based on REST and worth looking at. >> There was a lot to learn from for me as the API is pretty neat. > > > Thanks. We do our best to make the REST API of MedRecord as simple as > possible. We try to base the development of the API on actual usecases > and what kind of information in needed by (UI) clients without > requiring the users of our API to have any knowledge about openEHR or > know how things should work from a medical point of view. > > > This has lead to our current version of MedRecord (which is still work > in progress) and can be found here: > > https://mr.dev.medvision360.org/mr/apidocs/#!/ > > (see below if you want to try the API) > > > Since we want to make it easy for web application to access our APIs, > we should use whatever technique works best for web applications. > Currently this means we must use REST over HTTP, HATEOAS, JSON > documents, JSON schemas and a focus on (good) (API) documentation. > > I do think the REST architecture style is better than most SOAP, CORBA > and ESB solutions and it currently is the best way to access remote > resources. But doing REST properly is not easy. > > The current API of MedRecord consists of two pieces: > A fully automatically generated API based on the ADL files. > (everything starting with /ehr ) > And an API based on procedures (everything starting with /procedure ) > > The main difference is that the procedure API can be used without any > knowledge of openEHR. All openEHR difficulties are hidden behind the > procedure API which should make the API simple enough to be usable by > any (UI) developer not familiar with openEHR or health care. > > These two APIs are different views on the openEHR data stored in a > database. This also means we can swap the backend which we are > currently using for any other openEHR backend. > > The MedRecord API also comes with Java (and JavaScript) client > libraries which hides all the REST stuff which makes accessing > resources as simple a single line of code while providing the data as > plain old Java objects. > > Also note we have two versions of MedRecord. A version based on XML > and a version not based on XML. > Our current focus lies on the version without XML and this is the > version which can be seen in the link above. > > > Since our API needs authentication, you can test our API if you go to > the following page: > > https://mr.dev.medvision360.org/mr/apidocs/#!/ > > and use the text helloletmeinplease as authToken parameter. > > For example: > > https://mr.dev.medvision360.org/mr/ehr?authToken=helloletmeinplease > > lists all EHRs currently in our development server. > > > Btw. this answer might be slightly off-topic but I wanted to explain > the process of how we developed our current API. > > > Ralph. > > MedVision360 > > >
