Changes between Version 30 and Version 31 of UniformClearinghouseAPIV2

12/10/13 11:52:50 (6 years ago)

Incorporation of Wim's comments through #16


  • UniformClearinghouseAPIV2

    v30 v31  
    8787 * ROLES : A list of recognized roles for slice/project membership (optional for those Slice Authorities supporting membership).  ''[Required for SA only]''
    8888 * 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.
    8990 * FIELDS: A dictionary of object field names (i.e. in additional to the required fields) and associated attributes including:
    9091     * “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.
    99100Supplementary 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.).
     102The 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:
     104    "API_VERSIONS": {
     105         "1" : "",
     106         "2" : ""
     107      }   
    101110The 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.
    497506The 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.
    498507It 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:
     508The current service URL (provided in the SERVICE_URL field) should always be included in the SERVICE_PEERS.
     509The 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.
     510An example would be as follows:
    878889|| STRING || Generic UTF-8 string ||  ||
    879890|| 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 ||
    881892|| EMAIL || Well-formed email address || '''Example:''' ||
    882893|| KEY || SSH or SSL public or private key (contents, not filename) || Key-specific format ||