Changes between Version 30 and Version 31 of UniformClearinghouseAPIV2
- Timestamp:
- 12/10/13 11:52:50 (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
UniformClearinghouseAPIV2
v30 v31 87 87 * ROLES : A list of recognized roles for slice/project membership (optional for those Slice Authorities supporting membership). ''[Required for SA only]'' 88 88 * SERVICE_TYPES. A list of service types provided by the Federation Registry ''[Required for Federation Registry only]'' 89 * API_VERSIONS A dictionary of different peer implementation of different version of the same service. This field is optional for all services. 89 90 * FIELDS: A dictionary of object field names (i.e. in additional to the required fields) and associated attributes including: 90 91 * “OBJECT” provides the object type to which the field belongs. The field is optional for fields of the default authority object (i.e. SLICE for Slice Authority, MEMBER for Member Authority, SERVICE for Federation Registry) but mandatory for all other fields. … … 98 99 99 100 Supplementary field names should be placed in a distinct namespace by a prefix unique to that federation, and starting with an underscore (e.g. _GENI_, _OFELIA_ , _FED4FIRE_ or _PROTOGENI_ etc.). 101 102 The API_VERSIONS field of the get_version should contain a dictionary specifying different URL's implementing different versions of the same service. This information may be used by the Federation Registry to provide SERVICE_PEERS information described below. An example API_VERSIONS field from a get_version call: 103 {{{ 104 "API_VERSIONS": { 105 "1" : "https://example.com/xmlrpc/sa/1", 106 "2" : "https://example.com/xmlrpc/sa/2" 107 } 108 }}} 100 109 101 110 The return from the get_version call will be used to construct and validate options to Registry and Authority API calls, as described in subsequent sections. … … 497 506 The SERVICE_PEERS field is similar to that in the AM API: a list of {version", 'url'} dictionaries for other supported peer services of different versions. 498 507 It is provided to allow a user/tool to determine which URL to contact without needing to poll the get_version call across a set of services. 499 The current service URL (provided in the SERVICE_URL field) should always be included in the SERVICE_PEERS. An example would be as follows: 508 The current service URL (provided in the SERVICE_URL field) should always be included in the SERVICE_PEERS. 509 The information provided by SERVICE peers should be consistent with that provided by the API_VERSIONS field from the get_version call to these specific services. 510 An example would be as follows: 500 511 {{{ 501 512 [ … … 878 889 || STRING || Generic UTF-8 string || || 879 890 || INTEGER || Generic integer argument || || 880 || DATETIME || Date time in UTC format || '''Examples:''' 2013-06-15 02:39:08 2013-06-15 02:39:08-05:00 '''Details:''' Assumed in GMT time zone unless specified: '''GMT:''' YYYY-MM-DD HH:mm:ss '''Time zone offset specified:''' YYYY-MM-DD HH:mm:ss-HH:mm ||891 || DATETIME || Date time in RFC3339 format || '''Examples:''' 2013-06-15 02:39:08.25+0300 2013-06-15 02:39:08-05:00 '''Details:''' Timezone offset must be specified. Format: YYYY-MM-dd HH-mm-<seconds><timezone> where <seconds> may include decimal (to millisecond granularity) and <timezone> may be +HH:mm or -HH:mm || 881 892 || EMAIL || Well-formed email address || '''Example:''' jbrown@geni.net || 882 893 || KEY || SSH or SSL public or private key (contents, not filename) || Key-specific format ||