Support for WADO-URI

[CPBridge]

We have a need to deal with some equipment that does not expose its full WADO functionality through WADA-RS and requires the use of WADO-URI for some WADO features.

Would you entertain a PR that adds support for the WADO-URI? I think this should be pretty straightforward to implement and we would be happy to work on it.

If so, I would appreciate your thoughts on how the API could look. I envision that we would add the option to use WADO-URI to the existing retrieve_... methods. This could be done either as an optional parameter to the relevant methods, or as a global configuration option in the client's constructor. I think I favour the former despite it being more verbose. Thoughts? @hackermd

[hackermd]

So far, we only considered the RESTful Web Services and ignored the URI Web Service.

I am not sure whether we should try to integrate both services in the exiting class, given that the URI service only supports retrieve transactions, but not the search and store transactions. Furthermore, the retrieve transaction of the URI service only supports retrieval at the instance level (and to a certain extent at the frame level, but only a single frame can be retrieved per request). Therefore, the only methods that are useful for the URI Service are retrieve_instance, retrieve_instance_rendered, retrieve_instance_frames, and retrieve_instance_frames_rendered.

If we think that it would be valuable to add support for the URI Web Service to the library, I would suggest implementing a separate class (e.g., DICOMwebUriClient or something along those lines) that only has the above retrieve methods.

[CPBridge]

Thanks for the reply, these are good points. I will play around with creating a DICOMwebUriClient

[ntenenz]

Have you considered leveraging a DIMSE/DICOMweb adapter (if you're able to deploy server-side)?