This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

Should You Care about REST Advantages?

Stefan Tilkov,

In a comment, Marc de Graauw points to a blog entry where he writes:

[W]hen do the advantages of REST (caching, linking and bookmarking to name some) matter less? For one of my customers I design part of the Dutch national healthcare exchange, which is used to exchange patient data between care providers. Nearly all messages involved include the patient id: therefore most messages are pretty unique, and tied to a particular care context: say a patient visits his GP, or collect medication from his apothecary. In such exchanges, caching doesn’t matter at all. It is possible some data (a patients medication history) is retrieved twice when the patient visits two doctors after another, but in general in such an infrastructure it’s better to simple turn off caching, GET the data twice in the outlier cases and not be bothered by the overhead involved in caching.

Without any particularly evolved knowledge about the domain, I would still argue that there is probably a whole bunch of possible resource where caching would make a lot of sense in this case — a pharmacy, a doctor, a regulation, an insurance company … and even for those cases tied to a particular patient, the fact that he can bookmark his personal information record, his history, and other personal information would be very useful. In other words: I’m reasonably confident that Marc’s design could benefit from being converted to a REST approach — the fact that the patient ID is part of the message does not seem related to the problem domain, but rather to the solution domain.

On June 12, 2007 2:29 PM, Marc de Graauw said:

I have my doubts about the caching for this case, but I certainly agree with the possible advantages of bookmarking and linking. Especially the ability to link documents to related resources in a uniform (URI’s) and widely supported way (HTTP + browsers or other HTTP-enabled apps) is a clear advantage.

On June 12, 2007 7:51 PM, Mark Baker said:

I think it would also be useful for Marc to look at the architectural properties that are gained, such as simplicity, scalability, evolvability, etc.. I’m pretty confident that he’d need those. If he does, and is not using the Web, then I’d be interested to know what architectural constraints he’s using to obtain them. Marc?

On June 13, 2007 8:32 PM, Marc de Graauw said:

Mark Baker: “I think it would also be useful for Marc to look at the architectural properties that are gained … Marc?”

True enough. We used HL7 + (a minimal set of) web services in Dutch Healthcare and I would like to do an analysis of what it would look like with REST, and where the pros and cons of that approach would be - unfortunately that’s not something for a single blog entry, let alone a comment. But your remark is right on spot.

On June 13, 2007 9:24 PM, Stefan Tilkov said:

We’re available for contract work in the Netherlands, BTW :-)

On June 14, 2007 10:36 PM, Mark Baker said:

Me too! 8-)

On June 14, 2007 11:51 PM, Stefan Tilkov said:

We’d also be able to form a team! ;-)