DICOMweb
DICOMweb
DICOMweb exchanges DICOM resources through HTTP. Its service is a family of resources; a transaction is one operation with a method, path, query rules, request representation, and response representation. The Studies service includes QIDO-RS search, WADO-RS retrieval, and STOW-RS storage. Other families cover WADO-URI, UPS worklists and notifications, storage commitment, modality worklists, performed procedure steps, and non-patient instances.
Aspose.Medical.Dicom.Web.DicomWebApplication resolves and dispatches transactions without owning an HTTP listener. A host translates an inbound HTTP request into DicomWebRequest, calls ProcessAsync, and writes the returned DicomWebResponse or exposes a DicomWebNotificationSession through WebSocket. The supplied ASP.NET Core adapter performs that translation. DicomWebClient is a separate HTTP user agent: it can call any compatible DICOMweb server and does not require DicomWebApplication on the remote side.
| Responsibility | Owner |
|---|---|
| Listener, TLS, routing to a service root, authentication, authorization, CORS, forwarded headers, HTTP limits | Host |
| Standard routes, request envelope validation, dispatch, capabilities, response model | DICOMweb application |
| Transaction logic and response representation selection | Standard handlers or application-defined handlers |
| Database, archive, candidate queries, stored objects, rendering, workflow state, subscription delivery | Application-provided services |
Hosting and handler choices are independent. Standard handlers can be registered directly on the hosting-neutral builder or through dependency injection in ASP.NET Core. A custom handler can likewise run with either host. You can combine standard service registration with replacement handlers for selected transactions; handler registration explains the replacement rule.
Start with the implementation decision, then use the host and client guides:
- Standard services and provider contracts describes the built-in transaction engines and the storage, search, representation, and workflow interfaces you supply.
- Worklist and procedure step workflows implements an atomic UPS/MPPS store and a small notification queue.
- Storage commitment and non-patient instances shows the remaining persistence contracts and paired client requests.
- Custom transaction handlers shows a complete replacement for one transaction and compares it with a standard provider.
- Representations and streaming covers media negotiation, transfer syntax, JPEG rendering, multipart bodies, and bulk frames.
- Hosting-neutral integration describes the request/result boundary for another HTTP host.
- ASP.NET Core integration includes a complete minimal server, endpoint mapping, scopes, and WebSockets.
- DICOMweb client covers all operation groups, typed results, streaming, and notifications.
- Client operation reference lists every high-level operation and meaningful overload.
- Protocol and API reference covers routes, content, query and header values, capabilities, search controls, and ownership.
The API supplies transaction building blocks. Which transactions appear in an application’s capabilities depends on registered handlers, declared representation media types, optional providers, and enabled routes. Availability alone is not a blanket DICOM conformance claim; verify the supported transactions and application-provided behavior against your deployment requirements.