Pros and Cons: Rest API x DICOM (in the context of a poller)

[Luiz Eduardo Guida Valmont]

Hi all,

Is there any reason to choose the DICOM Protocol over the Rest API?

I'm looking into developing a poller as per this thread's suggestion: https://groups.google.com/forum/#!msg/orthanc-users/EiO4KPVwSbU/dP6RkMF9g4AJ;context-place=forum/orthanc-users

Because just as that thread's OP, I also need to retry failed routing's. So the poll'er will have to communicate with a running Orthanc server. A two-way communication, by the way.

In a nutshell, there's going to be an external application that every now and then will interact with Orthanc. But there's the DICOM protocol and there's the Rest API and the events I can hook onto (OnStoredInstance, ReceivedInstanceFilter, IncomingHttpFilter, etc).

So far, I fail to see the benefits of choosing one over the other since it looks as though both provide the same hooks. MAYBE the deletion process will favour the Rest API. Truth be told, even though I can respond to ReceivedInstance filter, there isn't a equivalent for deleted instances; on the other hand, I can develop an IncomingHttpRequestFilter so as to forward an instance's deletion, for example.

Also of interest is access control. It is possible to shield the server behind a basic auth mechanism.

Hopefully I wasn't too confusing in trying to explain the context.

What are your thoughts?

Thanks in advance! =)

Luiz

[Sébastien Jodogne]

Hi,

This is a quick answer, other members of the community are free to expand on it.

The reason of choosing DICOM over the custom REST API of Orthanc, is interoperability. 

The REST API of Orthanc is non-standard, and is only implemented by Orthanc at the time being. If you need your software to interface with other manufacturers in a vendor-neutral way, you'll have to switch to the DICOM or DICOMweb protocols. In other words, DICOM protocol brings compatibility, whereas Orthanc REST API brings easier, more powerful scripting.

Sébastien-

[Bryan Dearlove]

It sounds as though you are looking to communicate outside of your zone of control. Orthanc does not do DICOM over TLS, so for security sake, if you are communicating over public networks I would look at peering and Rest API. 

The best way is to shield the server over a Proxy with Auth control and Cert based auth. I can provide more info if this is something you need to do over a public network. 

[Luiz Eduardo Guida Valmont]

Hi Sbastien,

Thanks for your input =)

For 99,999% of the solution, it'll be Orthanc/Orthanc communication. We're integrating with another system through DICOM and for this case DICOM protocol was chosen.

We'll most probably develop a polling system [ref 1] to guarantee the routing of images and this system will communicate with Orthanc through Orthanc Rest API, as per your suggestion and the reasearch we've done so far. Really it's the best choice because we can, for instance, expose a new "/transmit/[sopInstanceUID]/[target]" that will route a given image.

"most probably" because we'll discuss the proposed solution in a meeting early next week, though I'm pretty confident it won't change much.

ref 1: https://groups.google.com/forum/#!msg/orthanc-users/EiO4KPVwSbU/dP6RkMF9g4AJ;context-place=forum/orthanc-users

Thanks!

[Luiz Eduardo Guida Valmont]

Hi Bryan!

Thank you very much for your reply!

We'll definitely use secure channels since we're talking about exposing data outside the customer's network. Thankfully, these inside/outside communications will be Orthanc/Orthanc interfaces, so the Rest API seems to fit like a glove.

Have a good one! =)