Quick Index
User favorite resources new in XNAT 1.6.
Add: (use labels "rest","user")
/data/archive/users/favorites/{DATA_TYPE}
/data/archive/users/favorites/{DATA_TYPE}/{PROJECT_ID}
Managing users of specific projects.
There is no content with the specified labels
Add: (use labels "rest","project","config")
/data/archive/config/edit/image/dicom/{RESOURCE}
/data/archive/config/edit/projects/{PROJECT_ID}/image/dicom/{RESOURCE}
/data/archive/config/{PROJECT_ID}/archive_spec
/data/archive/projects/{PROJECT_ID}/archive_spec
There is no content with the specified labels
Add: (use labels "rest","visit")
/data/archive/projects/{PROJECT_ID}/protocols/{PROTOCOL_ID}
A number of the imaging session resource REST API calls support the in and out parameters (see below). Unlike many REST URL parameters, in and out are not processing directives or attribute values, but instead operate as taxonomies to help distinguish the origins of your archived data. This allows for the segregation of resources by their provenance in the generation process:
This is used often in pipeline processing. For example, when XNAT performs Freesurfer processing on a session, the processing inputs to Freesurfer are put in the in folder. These are usually a collection of files, some of which may not have existed in XNAT. All of the files output by Freesurfer are then placed in the out section. When retrieving processing results, it is often necessary to have the exact files on which the processing was performed.
Placement of resources into the in and out folders can have practical effects other than clarification of provenance. For example, download operations usually ignore the content of the in folders, given that that data usually originates from the acquired data, meaning that the contents of the in folder are really duplicates of the acquired data. Data contained in out folders is included as a download option, since it's assumed that users would want the reconstructed or extrapolated data for further analysis.
New in XNAT 1.5. (Pre-existing child URIs for the archive resources are supported here as well.)
New in XNAT 1.5. (Pre-existing child URIs for the archive resources are supported here as well.)
Add: (use labels "rest","httpsession")
(REST call to refresh logout timer)
There is no content with the specified labels
Add: (use labels "rest","PAR")
/data/archive/projects/{PROJECT_ID}/pars
There is no content with the specified labels
Add: (use labels "rest","DIR")
/data/archive/experiments/{EXPT_ID}/DIR
/data/archive/projects/{PROJECT_ID}/experiments/{EXPT_ID}/DIR
/data/archive/experiments/{EXPT_ID}/XAR
/data/archive/projects/{PROJECT_ID}/experiments/{EXPT_ID}/XAR
This is the rest API for the nrg_config service which provides generic configuration text file versioning and persistence.
There is no content with the specified labels
/data/services/protocols/project/{PROJECT_ID}/subject/{SUBJECT_ID}/visits
/data/services/protocols/project/{PROJECT_ID}/subject/{SUBJECT_ID}/visits/{VISIT_ID}
/data/services/protocols/project/{PROJECT_ID}/subject/{SUBJECT_ID}/generate/{TYPE}
/data/archive/projects/{PROJECT_ID}/visits/{VISIT_ID}
/data/archive/visits/{VISIT_ID}
/data/archive/projects/{PROJECT_ID}/subjects/{SUBJECT_ID}/visits
/data/archive/projects/{PROJECT_ID}/subjects/{SUBJECT_ID}/visits/{VISIT_ID}
/data/archive/projects/{PROJECT_ID}/visits/{VISIT_ID}/experiments
/data/archive/projects/{PROJECT_ID}/subjects/{SUBJECT_ID}/visits/{VISIT_ID}/experiments
/services/workflows/{PIPELINE_NAME}
/services/workflows/workflowid/{WORKFLOW_PRIMARY_KEY}
There is no content with the specified labels
Add: (use labels "rest","system")
/data/services/logging/{Analytics.EVENT_KEY}
/data/services/tokens/{OPERATION}
/data/services/tokens/{OPERATION}/{TOKEN}
/data/services/tokens/{OPERATION}/{TOKEN}/{SECRET}
/experiments/{ID}/...
As a convenience, experiment paths can be shorted by accessing the experiments API outside of the project scope. Instead of using /projects/ID/subjects/label/experiments/label/..., you can access the resource as /experiments/ID/.... The only difference is that outside of the project scope, you must use the Expt ID (accession number) which was generated by XNAT (something like SITE_ID_E00001). Project based labels are not unique across all projects, and thus can't be used to identify an experiment outside of project scope.
/projects/{ID}/experiments
There is also a /data/archive/projects/{ID}/experiments which will return you a list of the experiments for a given project. It doesn't support the child API elements though (no /data/archive/projects/TEST_PROJECT/experiments/SITE_E00001/scans..., just /data/archive/projects/experiments/SITE_E00001).
The /experiments and /projects/ID/experiments URIs support a limited number of filtering options. Currently they are hardcoded as:
PARAMETER NAME | Description | Type | Example |
ID | Accession number | STRING | ?ID=xxx |
label | Primary project's label | STRING | ?label=xxx |
xsiType | data type | STRING | ?xsiType=xnat:mrSessionData,xnat:ctSessionData |
date | DATE | ?date=01/31/2007-03/30/2007 | |
session_type | session_type of imageSessionData | STRING | ?session_type=xxx |
studyInstanceUID | UID of imageSessionData | STRING | ?studyInstanceUID=xxx |
Date values allow the specification of date ranges using the '-' character. String values allow the comparisons rather than equivalency using the * wildcard.
More: XML Paths Shortcuts
Table of Contents