可以关注技术大牛博客https://blog.csdn.net/zssureqh

WADO-URI

accept：请求中的accept表明客户端（通常是浏览器）自身能够支持的从服务器返回的数据类型，例如上图中支持image/webp,image/,/*;q=0.8表示图片的质量 
accept-encoding：表示客户端（通常是浏览器）支持的编码格式，通常用于压缩和解压缩 
accept-language：表示客户端（通常是浏览器）支持的字符集，通常跟乱码有关。 
因为DICOM文件有多种类型，主要有Single frame（简单的可以理解为一个DICOM文件内部只有一个图片）、Multi frame（一个DICOM文件有多个图片）。每种类型在WADO-URI的Response返回结果中有所体现，大致如下：

请求中唯一与DICOM有关的是GET请求的参数 

WADO-URI的query参数主要有以下几类： 

 针对于DICOM Image图像有如下可选参数

下面直接给出几个具体示例：

 WADO-RS

WADO-RS支持的操作有： 
- RetrieveStudy 
- RetrieveSeries 
- RetrieveInstance 
- RetrieveFrames 
- RetrieveBulkdata 
- RetrieveMetadata

上述操作的实现的功能可以直接从名称中看出来这里就不详细介绍了。由于WADO-RS是基于HTTP的GET来实现DICOM的交互的，因此需要将上述操作的结果封装到HTTP的Response中返回。对应的关系图如下所示： 

WADO-RS各个操作的格式：

最后看一下WADO-RS Retrieve Rendered Transaction，用于实现DICOM数据到图像格式的转换。请求的格式如下： 

针对各个级别的请求如下： 

对于DICOM图像格式转换，最重要的是请求中的{?parameter*}参数，参数详细配置如下： 

上述参数主要用于配置图像的区域和截取的窗宽窗位，与WADO-URI中的URL中的参数发挥的作用一致。具体的转换格式在“1#rendered-media-type”中给出，这个参数类似于WADO-URI中的&contentType=image%2Fjp2。 
由此可以看出WADO-RS与WADO-URI的实现方式是类似的，除了在获取基础对象（Study、Series、Instance）时刻的方式不同（WADO-URI时基于&拼接完成的URL字符串，而WADO-RS是利用的REST实现框架），参数的传递方式是一样的。通过在资源定位URI后的{?parameter*}参数来实现转换操作。或者说WADO-RS仅仅是将WADO-URI放在基础URI后面{?parameter*}参数中的三级UID（studyUID、seriesUID、objectUID）挪到了URI中，仅仅在{?parameter*}中传递转换操作的相关参数。

3.总结

由最初的WADO-URI，到WADO-WS，再到WADO-RS，实现框架越来越简捷清晰，开发工作越来越方便。虽然上文介绍了诸多繁琐的标准和条款，但是其本质是一样的，最终都需要落实到DICOM的解析、DICOM的格式转换、DICOM的存储上来。这也是DICOM标准委员会制定标准的初衷，只规定与医疗服务相关的协议和标准，对于具体的实现路径不做强制约束。