├── .gitignore ├── Images ├── Topology1.png ├── Topology2.png └── Topology3.png ├── OAuth2Examples.md ├── README.md └── schemas ├── auth_GET.json ├── dynRegClient_GET.json ├── dynRegClient_POST.json ├── error.json ├── user_GET.json └── versions_GET.json /.gitignore: -------------------------------------------------------------------------------- 1 | .idea 2 | -------------------------------------------------------------------------------- /Images/Topology1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/buildingSMART/foundation-API/2c552eae435d575f1df7c11ff9ea19e3d2a324ce/Images/Topology1.png -------------------------------------------------------------------------------- /Images/Topology2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/buildingSMART/foundation-API/2c552eae435d575f1df7c11ff9ea19e3d2a324ce/Images/Topology2.png -------------------------------------------------------------------------------- /Images/Topology3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/buildingSMART/foundation-API/2c552eae435d575f1df7c11ff9ea19e3d2a324ce/Images/Topology3.png -------------------------------------------------------------------------------- /OAuth2Examples.md: -------------------------------------------------------------------------------- 1 | # Open CDE APIs OAuth2 Example 2 | 3 | This example describes an example OAuth2 workflow using the _Authorization Code Grant_ flow as per [section 4.1 of the OAuth2 specification](https://tools.ietf.org/html/rfc6749#section-4.1). Uris of required endpoints are assumed to have been obtained from the authentication resource as described in [section 2.2 of the Foundation API specification](README.md#221-obtaining-authentication-information). 4 | 5 | For this example, it is assumed that the client has been registered with the server in advance and has been issued valid credentials in the form of `client_id` and `client_secret`. 6 | 7 | ## Client Request 8 | 9 | To initiate the workflow, the client sends the user to the **"oauth2\_auth_url"** with the following parameters added: 10 | 11 | |parameter|value| 12 | |-------------|------| 13 | |response_type|`code` as string literal| 14 | |client_id|your client id| 15 | |state|unique user defined value| 16 | |redirect_url|The `redirect_url` registered for your client. This parameter is optional for OAUTH servers that don't support multiple redirect URLs| 17 | 18 | Example URL: 19 | 20 | GET https://example.com/foundation/oauth2/auth?response_type=code&client_id=&state=&redirect_url=https://YourWebsite.com/retrieveCode 21 | 22 | _On Windows operating systems, it is possible to open the systems default browser by using the url to start a new process._ 23 | 24 | Example redirected URL: 25 | 26 | https://YourWebsite.com/retrieveCode?code=&state= 27 | 28 | The Open CDE API server will ask the user to confirm that the client may access resources on his behalf. On authorization, the server redirects to an url that has been defined by the client author in advance. The generated `code` parameter will be appended as query parameter. Additionally, the `state` parameter is included in the redirection, it may be used to match server responses to client requests issued by your application. 29 | 30 | If the user denies client access, there will be an `error` query parameter in the redirection indicating an error reason as described in [section 4.1.2.1 of the OAuth2 specification](https://tools.ietf.org/html/rfc6749#section-4.1.2.1). 31 | 32 | ## Token Request 33 | 34 | With the obtained _authorization code_, the client is able to request an access token from the server. The **"oauth2\_token_url"** from the authentication resource is used to send token requests to, for example: 35 | 36 | POST https://example.com/foundation/oauth2/token 37 | 38 | The POST request should be done via HTTP Basic Authorization with your applications `client_id` as the username and your `client_secret` as the password. 39 | 40 | **Example Request** 41 | 42 | POST https://example.com/foundation/oauth2/token?grant_type=authorization_code&code= 43 | 44 | The access token will be returned as JSON in the response body and is an arbitrary string. There is no maximum length, per [oauth2 documentation](https://tools.ietf.org/html/rfc6749#section-1.4). 45 | 46 | **Response parameters** 47 | 48 | |parameter|type|description| 49 | |---------|----|-----------| 50 | |access_token|string|The issued OAuth2 token| 51 | |token_type|string|Always `bearer`| 52 | |expires_in|integer|The lifetime of the access token in seconds| 53 | |refresh_token|string|The issued OAuth2 refresh token, one-time-usable only| 54 | 55 | **Example Response** 56 | 57 | Response Code: 201 - Created 58 | Body: 59 | { 60 | "access_token": "Zjk1YjYyNDQtOTgwMy0xMWU0LWIxMDAtMTIzYjkzZjc1Y2Jh", 61 | "token_type": "bearer", 62 | "expires_in": "3600", 63 | "refresh_token": "MTRiMjkzZTYtOTgwNC0xMWU0LWIxMDAtMTIzYjkzZjc1Y2Jh" 64 | } 65 | 66 | ## Refresh Token Request 67 | 68 | The process to retrieve a refresh token is exactly the same as retrieving a token via the code workflow except the `refresh_token` is sent instead of the `code` parameter and the `refresh_token` grant type is used. 69 | 70 | **Example Request** 71 | 72 | POST https://example.com/foundation/oauth2/token?grant_type=refresh_token&refresh_token= 73 | 74 | The access token will be returned as JSON in the response body and is an arbitrary string. 75 | 76 | **Example Response** 77 | 78 | Response Code: 201 - Created 79 | Body: 80 | { 81 | "access_token": "Zjk1YjYyNDQtOTgwMy0xMWU0LWIxMDAtMTIzYjkzZjc1Y2Jh", 82 | "token_type": "bearer", 83 | "expires_in": "3600", 84 | "refresh_token": "MTRiMjkzZTYtOTgwNC0xMWU0LWIxMDAtMTIzYjkzZjc1Y2Jh" 85 | } 86 | 87 | The refresh token can only be used once to retrieve a token and a new refresh token. 88 | 89 | ## Requesting Resources 90 | 91 | When requesting other resources the access token must be passed via the `Authorization` header using the `Bearer` scheme (e.g. `Authorization: Bearer Zjk1YjYyNDQtOTgwMy0xMWU0LWIxMDAtMTIzYjkzZjc1Y2Jh`). 92 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | [![Official repository by buildingSMART International](https://img.shields.io/badge/buildingSMART-Official%20Repository-orange.svg)](https://www.buildingsmart.org/) 2 | [![This repo is managed by the OpenCDE APIs Implementers Group](https://img.shields.io/badge/-BCF%20Implementers%20Group-blue.svg)](https://img.shields.io/badge/-BCF%20Implementers%20Group-blue.svg) 3 | 4 | ![buildingSMART_RGB_FoundationAPI_v4](https://github.com/user-attachments/assets/4fc5dc1d-2a0c-4e56-882b-94841a6ee920) 5 | 6 | **Version 1.1** Released together with Documents API 1.0. 7 | [BCF API GitHub repository](https://github.com/buildingSMART/documents-API/tree/release_1_0) 8 | 9 | **Contributing** 10 | 11 | The Open CDE workgroup develops the Foundation API standard. 12 | 13 | 14 | **Table of Contents** 15 | 16 | 17 | 18 | - [1. Introduction](#1-introduction) 19 | * [1.1 Paging, Sorting and Filtering](#11-paging-sorting-and-filtering) 20 | * [1.2 Caching](#12-caching) 21 | * [1.3 Updating Resources via HTTP PUT](#13-updating-resources-via-http-put) 22 | * [1.4 Cross Origin Resource Sharing (CORS)](#14-cross-origin-resource-sharing-cors) 23 | * [1.5 Http Status Codes](#15-http-status-codes) 24 | + [1.5.1 Conflict on creation](#151-conflict-on-creation) 25 | * [1.6 Error Response Body Format](#16-error-response-body-format) 26 | * [1.7 DateTime Format](#17-datetime-format) 27 | * [1.8 Additional Response and Request Object Properties](#18-additional-response-and-request-object-properties) 28 | * [1.9 Binary File Uploads](#19-binary-file-uploads) 29 | * [1.10 Differences Between null and Empty Lists](#110-differences-between-null-and-empty-lists) 30 | * [1.11 HTTPS/TLS](#111-httpstls) 31 | - [2. Public Services](#2-public-services) 32 | * [2.1 Versions Service](#21-versions-service) 33 | * [2.2 Authentication Services](#22-authentication-services) 34 | + [2.2.1 Obtaining Authentication Information](#221-obtaining-authentication-information) 35 | + [2.2.2 OAuth2 Example](#222-oauth2-example) 36 | + [2.2.3 OAuth2 Protocol Flow - Dynamic Client Registration](#223-oauth2-protocol-flow---dynamic-client-registration) 37 | - [3. Directory Services](#3-directory-services) 38 | * [3.1 User Services](#31-user-services) 39 | + [3.1.1 Get current user](#311-get-current-user) 40 | 41 | 42 | 43 | 44 | # 1. Introduction 45 | 46 | The OpenCDE Foundation API includes a small number of services and a few conventions that are common to all OpenCDE APIs. 47 | 48 | OpenCDE APIs support the exchange of information between software applications via a [RESTful](https://en.wikipedia.org/wiki/Representational_state_transfer) web interface, which means that data is exchanged via HTTP query parameters and JSON payloads. 49 | URL schemas in this README are relative to the OpenCDE API servers' base-URL unless an absolute value is provided. 50 | 51 | ## 1.1 Paging, Sorting and Filtering 52 | 53 | When requesting collections of items, the Server should offer URL parameters according to the [OData v4 specification](http://www.odata.org/documentation/). 54 | 55 | ## 1.2 Caching 56 | 57 | ETags, or entity-tags, are an important part of HTTP, being a critical part of caching, and also used in "conditional" requests. 58 | 59 | The ETag response-header field value, an entity tag, provides for an "opaque" cache validator. 60 | The easiest way to think of an etag is as an MD5 or SHA1 hash of all the bytes in a representation. If just one byte in the representation changes, the etag will change. 61 | 62 | ETags are returned in a response to a GET: 63 | 64 | joe@joe-laptop:~$ curl --include http://bitworking.org/news/ 65 | HTTP/1.1 200 Ok 66 | Date: Wed, 21 Mar 2007 15:06:15 GMT 67 | Server: Apache 68 | ETag: "078de59b16c27119c670e63fa53e5b51" 69 | Content-Length: 23081 70 | … 71 | 72 | The client may send an "If-None-Match" HTTP Header containing the last retrieved etag. If the content has not changed the server returns a status code 304 (not modified) and no response body. 73 | 74 | ## 1.3 Updating Resources via HTTP PUT 75 | 76 | Whenever a resource offers the HTTP PUT method, it is to be updated as a whole. 77 | 78 | This means that there is no partial update mechanism for objects but every PUT request is sending the whole object representation. 79 | 80 | ## 1.4 Cross Origin Resource Sharing (CORS) 81 | 82 | To work with browser based API clients using [Cross Origin Resource Sharing (Cors)](https://en.wikipedia.org/wiki/Cross-origin_resource_sharing), servers will put the `Access-Control-Allow'` headers in the response headers and specify who can access the servers JSON resources. The client can look for these values and proceed with accessing the resources. 83 | 84 | In a CORS scenario, web clients expect the following headers: 85 | * `Access-Control-Allow-Headers: Authorization, Content-Type, Accept` to allow the `Authorization`, `Content-Type` and `Accept` headers to be used via [XHR requests](https://en.wikipedia.org/wiki/XMLHttpRequest) 86 | * `Access-Control-Allow-Methods: GET, POST, PUT, OPTIONS` to allow the Http methods the API needs 87 | * `Access-Control-Allow-Origin: example.com` to allow XHR requests from the `example.com` domain to the API server 88 | 89 | For example, Asp.Net applications in IIS need the following entries in their `web.config` file. `*` means the server allows any values. 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | ## 1.5 Http Status Codes 100 | 101 | Web-based APIs rely on the regular Http Status Code definitions. Good sources are [Wikipedia](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes) or the [HTTP/1.1 Specification](https://tools.ietf.org/html/rfc7231). 102 | 103 | Generally, these response codes shall be used in the API: 104 | * `200 - OK` for `GET` requests that return data or `PUT` requests that update data 105 | * `201 - Created` for `POST` requests that create data 106 | * `401 - Unauthorized` for requests that have errors when the user is not authenticated 107 | * `403 - Forbidden` for requests when the user is authenticated but not authorized to perform the operation 108 | 109 | `POST` and `PUT` requests do usually include the created/modified resource in the response body. Exceptions to this rule are described in the specific section for the resource. 110 | 111 | ### 1.5.1 Conflict on creation 112 | 113 | For resource creation by `POST` with optional GUID specified, if the GUID already exists in the target system, status code `409 - Conflict` will be returned. 114 | 115 | ## 1.6 Error Response Body Format 116 | 117 | All OpenCDE APIs have a specified error response body format [error.json](schemas/error.json). 118 | 119 | ## 1.7 DateTime Format 120 | 121 | DateTime values must be [rfc3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) compliant. 122 | 123 | Examples: 124 | * `2016-04-28T16:31:12Z` would represent _Thursday, April 28th, 2016, 16:31:12 (0ms) in UTC timezone._ 125 | * `2016-04-28T16:31:12.270Z` would represent _Thursday, April 28th, 2016, 16:31:12 (270ms) in UTC timezone._ 126 | * `2016-04-28T16:31:12.270+02:00` would represent _Thursday, April 28th, 2016, 16:31:12 (270ms) with a time zone offset of +2 hours relative to UTC._ 127 | 128 | ## 1.8 Additional Response and Request Object Properties 129 | 130 | All API response and request JSON objects may contain additional properties that are not part of the specified exchange for that endpoint. 131 | This is to allow server and client implementations freedom to add additional functionality. Servers and clients shall ignore those properties and must not produce errors on additional properties. Servers and clients are not required to preserve these properties. 132 | 133 | ## 1.9 Binary File Uploads 134 | 135 | Some endpoints may expect binary file uploads, such as the BCF Document Service and the BCF BIM Snippet Service. 136 | 137 | In such cases, files should be sent with the following Http headers: 138 | 139 | Headers: 140 | Content-Type: application/octet-stream; 141 | Content-Length: {Size of file in bytes}; 142 | Content-Disposition: attachment; filename="{Filename.extension}"; 143 | 144 | ## 1.10 Differences Between null and Empty Lists 145 | 146 | Some array or list properties and responses can be interpreted differently if they are either `null` or empty. In general, there are two cases to consider. 147 | 148 | **For collection resources:** 149 | 150 | * A collection resource that does not exist should return Http error `404 - Not Found`, e.g. the list of topics for an invalid project id. 151 | * If the resource exists but there are no elements, the returned response should be an empty array `[]`, e.g. the list of topics for a project where no topics exist. 152 | 153 | **For properties:** 154 | 155 | * If a list property is `null` (by explicitly setting it to null or not returning it in the response object at all), the client should not assume that this represents an empty list but instead the property is not present on the response object. Depending on the response object, this can have the same meaning as an empty list (e.g. no components in a viewpoint is the same as an empty list of components), but this can also mean the property is just omitted for optional properties (e.g. no `topic_actions` in an `authorization` object can mean no restrictions). 156 | 157 | ## 1.11 HTTPS/TLS 158 | 159 | To ensure the security of API exchanges servers should only expose API endpoints over HTTPS with a minimal TLS version of 1.2. 160 | 161 | ---------- 162 | 163 | # 2. Public Services 164 | 165 | ## 2.1 Versions Service 166 | 167 | [versions_GET.json](schemas/versions_GET.json) 168 | 169 | The Versions service is used to discover the available OpenCDE APIs and where to find them. The `api_base_url` field specifies the base path for each API. 170 | 171 | To clarify, the Versions service allows specifying `api_base_url` for the Foundation API. However, to ensure discoverability, the Versions service is always served from the `/foundation/versions` base path regardless of the `api_base_url` parameter value. 172 | 173 | **Resource URL (public resource)** 174 | 175 | GET /foundation/versions 176 | 177 | **Parameters** 178 | 179 | |Parameter|Type|Description|Required| 180 | |---------|----|-----------|--------| 181 | |api_id|string|Identifier of the API|true| 182 | |version_id|string|Identifier of the version|true| 183 | |detailed_version|string|URL of the specification on GitHub|false| 184 | |api_base_url|string|An optional, fully qualified URL, to allow servers to relocate the API|false| 185 | 186 | Returns a list of all supported OpenCDE APIs and their versions. 187 | 188 | **Example Request** 189 | 190 | GET /foundation/versions 191 | 192 | **Example Response** 193 | 194 | Response Code: 200 - OK 195 | Body: 196 | { 197 | "versions": [{ 198 | "api_id": "foundation", 199 | "version_id": "1.1", 200 | "detailed_version": "https://github.com/BuildingSMART/foundation-API/tree/release_1_1" 201 | "api_base_url": "https://server.base.url/foundation/1.1" 202 | }, { 203 | "api_id": "bcf", 204 | "version_id": "2.1", 205 | "detailed_version": "https://github.com/buildingSMART/BCF-API/tree/release_2_1", 206 | "api_base_url": "https://server.base.url/bcf/2.1" 207 | }, { 208 | "api_id": "bcf", 209 | "version_id": "3.0", 210 | "detailed_version": "https://github.com/buildingSMART/BCF-API/tree/release_3_0", 211 | "api_base_url": "https://server.base.url/somepath/bcf/3.0" 212 | }, { 213 | "api_id": "documents", 214 | "version_id": "1.0", 215 | "detailed_version": "https://github.com/buildingSMART/documents-API/tree/release_1_0", 216 | "api_base_url": "https://server.base.url/somepath/documents/1.0" 217 | }] 218 | } 219 | 220 | ## 2.2 Authentication Services 221 | 222 | ### 2.2.1 Obtaining Authentication Information 223 | 224 | [auth_GET.json](schemas/auth_GET.json) 225 | 226 | Authentication is based on the [OAuth 2.0 Protocol](https://tools.ietf.org/html/rfc6749). 227 | 228 | **Resource URL (public resource)** 229 | 230 | GET /foundation/{version}/auth 231 | 232 | **Parameters** 233 | 234 | |Parameter|Type|Description|Required| 235 | |---------|----|-----------|--------| 236 | |oauth2_auth_url|string|URL to authorization page (used for Authorization Code Grant and Implicit Grant OAuth2 flows)|false| 237 | |oauth2_token_url|string|URL for token requests|false| 238 | |oauth2_dynamic_client_reg_url|string|URL for automated client registration|false| 239 | |http_basic_supported|boolean|Indicates if Http Basic Authentication is supported|false| 240 | |supported_oauth2_flows|string[]|array of supported OAuth2 flows|true| 241 | 242 | If `oauth2_auth_url` is present, then `oauth2_token_url` must also be present and vice versa. If properties are not present in the response, clients should assume that the functionality is not supported by the server, e.g. a missing `http_basic_supported` property would indicate that Http basic authentication is not available on the server. 243 | 244 | OAuth2 flows are described in detail in the [OAuth2 specification](https://tools.ietf.org/html/rfc6749). OpenCDE API servers may support the following flows: 245 | * `authorization_code_grant` - [4.1 - Authorization Code Grant](https://tools.ietf.org/html/rfc6749#section-4.1) 246 | * `implicit_grant` - [4.2 - Implicit Grant](https://tools.ietf.org/html/rfc6749#section-4.2) 247 | * `resource_owner_password_credentials_grant` - [4.3 - Resource Owner Password Credentials Grant](https://tools.ietf.org/html/rfc6749#section-4.3) 248 | 249 | The [OAuth2 Client Credentials Grant (section 4.4)](https://tools.ietf.org/html/rfc6749#section-4.4) is not supported since it does not contain any user identity. 250 | Also the [Extension Grants (section 4.5)](https://tools.ietf.org/html/rfc6749#section-4.5) are not supported. 251 | 252 | **Example Request** 253 | 254 | GET /foundation/{version}/auth 255 | 256 | **Example Response** 257 | 258 | Response Code: 200 - OK 259 | Body: 260 | { 261 | "oauth2_auth_url": "https://example.com/foundation/oauth2/auth", 262 | "oauth2_token_url": "https://example.com/foundation/oauth2/token", 263 | "oauth2_dynamic_client_reg_url": "https://example.com/foundation/oauth2/reg", 264 | "http_basic_supported": true, 265 | "supported_oauth2_flows": [ 266 | "authorization_code_grant", 267 | "implicit_grant", 268 | "resource_owner_password_credentials_grant" 269 | ] 270 | } 271 | 272 | ### 2.2.2 OAuth2 Example 273 | 274 | An example for the OAuth2 Authorization Grant workflow [can be found here](OAuth2Examples.md). 275 | 276 | ### 2.2.3 OAuth2 Protocol Flow - Dynamic Client Registration 277 | 278 | [dynRegClient\_POST.json](schemas/dynRegClient_POST.json) 279 | 280 | [dynRegClient\_GET.json](schemas/dynRegClient_GET.json) 281 | 282 | The following part describes the optional dynamic registration process of a client. OpenCDE API Servers may offer additional processes registering clients, for example allowing a client application developer to register his client on the servers website. 283 | 284 | The resource url for this service is server specific and is returned as `oauth2_dynamic_client_reg_url` in the `GET /foundation/{version}/auth` resource. 285 | 286 | Register a new client : 287 | 288 | **Parameters** 289 | 290 | JSON encoded body using the `application/json` content type. 291 | 292 | |parameter|type|description| 293 | |---------|----|-----------| 294 | |client_name|string|The client name| 295 | |client_description|string|The client description| 296 | |client_url|string|An URL providing additional information about the client| 297 | |redirect_url|string|An URL where users are redirected after granting access to the client| 298 | 299 | **Example Request** 300 | 301 | POST https://example.com/foundation/oauth2/reg 302 | Body: 303 | { 304 | "client_name": "Example Application", 305 | "client_description": "Example CAD desktop application", 306 | "client_url": "http://example.com", 307 | "redirect_url": "http://localhost:8080" 308 | } 309 | 310 | **Example Response** 311 | 312 | Response Code: 201 - Created 313 | Body: 314 | { 315 | "client_id": "cGxlYXN1cmUu", 316 | "client_secret": "ZWFzdXJlLg==" 317 | } 318 | 319 | ---------- 320 | 321 | # 3. Directory Services 322 | 323 | ## 3.1 User Services 324 | 325 | ### 3.1.1 Get current user 326 | 327 | [user_GET.json](schemas/user_GET.json) 328 | 329 | **Resource URL** 330 | 331 | GET /foundation/{version}/current-user 332 | 333 | **Example Request** 334 | 335 | GET /foundation/1.0/current-user 336 | 337 | **Example Response** 338 | 339 | Response Code: 200 - OK 340 | Body: 341 | { 342 | "id": "Architect@example.com", 343 | "name": "John Doe" 344 | } 345 | 346 | 347 | -------------------------------------------------------------------------------- /schemas/auth_GET.json: -------------------------------------------------------------------------------- 1 | { 2 | "title": "auth_GET", 3 | "type": "object", 4 | "properties": { 5 | "oauth2_auth_url": { 6 | "type": ["string", 7 | "null"] 8 | }, 9 | "oauth2_token_url": { 10 | "type": ["string", 11 | "null"] 12 | }, 13 | "oauth2_dynamic_client_reg_url": { 14 | "type": ["string", 15 | "null"] 16 | }, 17 | "http_basic_supported": { 18 | "type": ["boolean", 19 | "null"] 20 | }, 21 | "supported_oauth2_flows": { 22 | "type": ["array", 23 | "null"], 24 | "items": { 25 | "type": ["string"] 26 | } 27 | } 28 | } 29 | } 30 | -------------------------------------------------------------------------------- /schemas/dynRegClient_GET.json: -------------------------------------------------------------------------------- 1 | { 2 | "title": "dyn_reg_client_GET", 3 | "description": "Dynamic Client Meta Data", 4 | "type": "object", 5 | "properties": { 6 | "client_id": { 7 | "type": "string", 8 | "required": true 9 | }, 10 | "client_secret": { 11 | "type": "string", 12 | "required": true 13 | } 14 | } 15 | } -------------------------------------------------------------------------------- /schemas/dynRegClient_POST.json: -------------------------------------------------------------------------------- 1 | { 2 | "title": "dyn_reg_client_POST", 3 | "description": "Dynamic Client Meta Data", 4 | "type": "object", 5 | "properties": { 6 | "client_name": { 7 | "type": "string", 8 | "required": true 9 | }, 10 | "client_description": { 11 | "type": "string", 12 | "required": false 13 | }, 14 | "client_url": { 15 | "type": "string", 16 | "required": false 17 | }, 18 | "redirect_url": { 19 | "type": "string", 20 | "required": true 21 | } 22 | } 23 | } -------------------------------------------------------------------------------- /schemas/error.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema": "http://json-schema.org/draft-03/schema#", 3 | "title": "Error", 4 | "description": "Schema for error, BSI REST APIs.", 5 | "type": "object", 6 | "properties": { 7 | "message": { 8 | "type": "string", 9 | "required": true 10 | } 11 | } 12 | } -------------------------------------------------------------------------------- /schemas/user_GET.json: -------------------------------------------------------------------------------- 1 | { 2 | "title": "user_GET", 3 | "type": "object", 4 | "properties": { 5 | "id": { 6 | "required": true, 7 | "type": "string" 8 | }, 9 | "name": { 10 | "type": ["string", 11 | "null"] 12 | } 13 | } 14 | } -------------------------------------------------------------------------------- /schemas/versions_GET.json: -------------------------------------------------------------------------------- 1 | { 2 | "title": "versions_GET", 3 | "description": "Schema for Versions", 4 | "type": "object", 5 | "properties": { 6 | "versions": { 7 | "required": true, 8 | "type": "array", 9 | "items": { 10 | "type": ["object", "null"], 11 | "properties": { 12 | "api_id": { 13 | "type": "string", 14 | "required": true 15 | }, 16 | "version_id": { 17 | "type": "string", 18 | "required": true 19 | }, 20 | "detailed_version": { 21 | "type": "string", 22 | "required": false 23 | }, 24 | "api_base_url": { 25 | "type": "string", 26 | "required": false 27 | } 28 | } 29 | } 30 | } 31 | } 32 | } 33 | --------------------------------------------------------------------------------