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.
