Restful webservice is widely used in all kinds of companies in China.
especially when the mobile health or mobile internet technology flood all over
the wolrd .but there is a thing we should notice these use cases are all in the
information exchange or work flow creation inside one company or ecosystem
around a company.in my opinion this micro service architecture is quite
suitable for building pc applications and mobile applications at the same time
based on the cloud computing and container development during these years.our
company,one of the leading health information exchange and health information
systems vendor are trying to switch to micro service architecture (not
alone,also some other paradigm) using Restful webservice to promote the
development of mobile application and integration between different products
definitely you can still solve everything with old hammer and nails.
perhaps more timely and cost-effective.
kind regards.
--
???
15901958021
At 2015-01-20 16:24:17, "Ralph van Etten" <ralph at medvision360.com> wrote:
>Hi Thomas,
>
>
>> The interesting question is: what style of service should be used for
>> e-health business entities, like active care plans, managed medication
>> lists, and order management, which all need much more complex APIs than
>> just 'get'? FHIR is not designed for this kind of thing, and it's
>> questionable whether REST is either.
>
>REST is more than just using GET to fetch resources.
>I think most, if not all, use cases can be cleanly and comfortably
>implemented using a REST style architecture.
>
>We did some work on care plans and medication lists but I did not found
>anything which would not fit the REST style architecture.
>
>What kind of use case do you think is too complex for or does not fit a
>REST architecture ?
>
>
>
>
>> The APIs in these cases need to be
>> carefully designed, and could easily be stateful / session-oriented -
>
>But following the REST architectural style does not mean you can't have
>a state. All clients have state, you just can't store this state on the
>server, you keep the state on the client.
>Same goes for sessions, you can still have sessions when using REST, you
>just don't store them on the server but on the client.
>
>
>> especially if they manage a shared resource that multiple agents may try
>> to update simultaneously.
>
>HTTP has pretty good standard methods for managing simultaneous updates
>of the same resource. Like the HTTP PATCH method, JSON patch documents
>and conditional requests. They all work without having to keep state on
>the server.
>I would say these techniques makes it much easier to do concurrent
>requests on the same resource, even when the requests are handled by
>multiple servers at the same time.
>
>
>> In any case, I don't see statefulness or not
>> as the decider on what kind of protocol you want; structure is a bigger
>> decider.
>> I think it's easy to fall into the trap of thinking a single latest /
>> fashionable protocol is good for all layers of a complex architecture.
>
>REST is not about the protocol. REST is an architectural style which is
>commonly implemented using the HTTP protocol.
>You can use any protocol you want, including SOAP and binary RPC, and
>still call it REST.
>
>You are correct in that if the structure of an application does not fit
>the REST style architecture, there are much better protocols than REST
>over HTTP to communicate with it.
>
>But we did not looked at our application and then thought about putting
>some REST API on top of that.
>We certainly did not choose REST because it is the 'latest/fashionable
>protocol' or 'hey, let's do what everyone else is doing'.
>
>We started from the other end: we looked at what is the most convenient
>way for (web) frontend developers to use our API. Because in the end the
>most important thing is how easy/quickly can someone create an user
>interface on top of our API. Currently that means using the HTTP
>protocol and JSON documents.
>
>Then we spend quite a bit of effort to determine which architectural
>style would fit our use cases best and we choose REST.
>We also made sure the REST architectural style is implemented all the
>way throughout our applications instead of just having a small 'REST'
>like API layer on top of something which does not fit REST very well.
>REST is more than just a small protocol layer for accessing a service.
>
>Further we are not trying to build a huge complex architecture but we
>try to keep things small and manageable with many small services which
>'do one thing and do them well'.
>By doing that we did not encounter anything too complex. Everything is
>split into small, self sustained, easily manageable and solvable pieces.
>I would almost say health care is not that complex after all... :-)
>
>
>Ralph.
>
>MedVision360
>
>
>--
>This e-mail message is intended exclusively for the addressee(s). Please
>inform us immediately if you are not the addressee.
>
>_______________________________________________
>openEHR-technical mailing list
>openEHR-technical at lists.openehr.org
>http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150120/f6b4e89b/attachment-0001.html>
