├── .node-version ├── FUNDING.yml ├── .gitignore ├── funding.json ├── bin ├── get-version.js ├── build.sh ├── build.markdown.sh └── build.ghpages.sh ├── .markdownlint.json ├── .github ├── workflows │ ├── label.yml │ └── greetings.yml ├── labeler.yml └── stale.yml ├── package.json ├── .releaserc ├── README.md ├── VERSIONING.md ├── .circleci └── config.yml ├── RELEASING.md ├── BUILDING.md ├── FAQ.md ├── CONTRIBUTING.md ├── CONVENTIONAL_COMMITS.md ├── LICENSE.md ├── CHANGELOG.md └── spec.md /.node-version: -------------------------------------------------------------------------------- 1 | 18.13.0 2 | -------------------------------------------------------------------------------- /FUNDING.yml: -------------------------------------------------------------------------------- 1 | open_collective: openrpc 2 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | .DS_Store 2 | build/ 3 | node_modules/ 4 | -------------------------------------------------------------------------------- /funding.json: -------------------------------------------------------------------------------- 1 | { 2 | "opRetro": { 3 | "projectId": "0x6f8f610667400044907494c879b717e806a03bf519dcfd786edc7f2fa61d6db8" 4 | } 5 | } 6 | -------------------------------------------------------------------------------- /bin/get-version.js: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env node 2 | module.exports = require('../package.json').version; 3 | if (require.main === module) { 4 | console.log(module.exports); 5 | } 6 | -------------------------------------------------------------------------------- /.markdownlint.json: -------------------------------------------------------------------------------- 1 | { 2 | "default": true, 3 | "MD033": { 4 | "allowed_elements": ["p", "img", "a"] 5 | }, 6 | "MD013": false, 7 | "MD025": false, 8 | "MD004": false 9 | } 10 | -------------------------------------------------------------------------------- /.github/workflows/label.yml: -------------------------------------------------------------------------------- 1 | name: "Pull Request Labeler" 2 | on: 3 | - pull_request_target 4 | 5 | jobs: 6 | triage: 7 | permissions: 8 | contents: read 9 | pull-requests: write 10 | runs-on: ubuntu-latest 11 | steps: 12 | - uses: actions/labeler@v4 13 | with: 14 | repo-token: "${{ secrets.GITHUB_TOKEN }}" 15 | -------------------------------------------------------------------------------- /.github/labeler.yml: -------------------------------------------------------------------------------- 1 | spec: spec.md 2 | 3 | deps: 4 | - package.json 5 | - package-lock.json 6 | 7 | deploy: 8 | - .circleci/**/* 9 | - bin/**/* 10 | - .releaserc 11 | 12 | ops: 13 | - .github/**/* 14 | - .markdownlint.json 15 | - README.md 16 | - .gitignore 17 | 18 | pristine: 19 | - BUILDING.md 20 | - CONTRIBUTING.md 21 | - CONVENTIONAL_COMMITS.md 22 | - RELEASING.md 23 | - VERSIONING.md 24 | - .gitignore 25 | 26 | license: LICENSE.md 27 | 28 | never: CHANGELOG.md 29 | -------------------------------------------------------------------------------- /.github/workflows/greetings.yml: -------------------------------------------------------------------------------- 1 | name: Greetings 2 | 3 | on: [pull_request, issues] 4 | 5 | jobs: 6 | greeting: 7 | runs-on: ubuntu-latest 8 | steps: 9 | - uses: actions/first-interaction@v1 10 | with: 11 | repo-token: ${{ secrets.GITHUB_TOKEN }} 12 | issue-message: 'Welcome to OpenRPC! Thank you for taking the time to create an issue. Please review the [guidelines](https://github.com/open-rpc/spec/blob/master/CONTRIBUTING.md)' 13 | pr-message: 'Welcome to OpenRPC! Thank you for taking the time to create an issue. Please review the [guidelines](https://github.com/open-rpc/spec/blob/master/CONTRIBUTING.md)' 14 | -------------------------------------------------------------------------------- /.github/stale.yml: -------------------------------------------------------------------------------- 1 | # Number of days of inactivity before an issue becomes stale 2 | daysUntilStale: 60 3 | # Number of days of inactivity before a stale issue is closed 4 | daysUntilClose: 7 5 | # Issues with these labels will never be considered stale 6 | exemptLabels: 7 | - pinned 8 | - security 9 | # Label to use when marking an issue as stale 10 | staleLabel: stale 11 | # Comment to post when marking an issue as stale. Set to `false` to disable 12 | markComment: > 13 | This issue has been automatically marked as stale because it has not had 14 | recent activity. It will be closed if no further activity occurs. Thank you 15 | for your contributions. 16 | # Comment to post when closing a stale issue. Set to `false` to disable 17 | closeComment: false 18 | -------------------------------------------------------------------------------- /bin/build.sh: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env node 2 | 3 | const {promisify} = require("util"); 4 | 5 | const readdir = promisify(require("fs").readdir); 6 | const execFile = promisify(require('child_process').execFile); 7 | const fsx = require("fs-extra"); 8 | 9 | const build = async () => { 10 | const buildScriptFilenames = await readdir(__dirname); 11 | 12 | const buildTargets = buildScriptFilenames 13 | .filter((filename) => filename.includes("build.") && filename !== "build.sh") 14 | .map((filename) => filename.split(".")[1]); 15 | 16 | await Promise.all(buildTargets.map((buildTarget) => require(`${__dirname}/build.${buildTarget}.sh`)())); 17 | 18 | console.log("build complete"); 19 | }; 20 | 21 | module.exports = build; 22 | 23 | if (require.main === module) { 24 | build(); 25 | } 26 | -------------------------------------------------------------------------------- /bin/build.markdown.sh: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env node 2 | 3 | const fsx = require("fs-extra"); 4 | const toc = require('markdown-toc'); 5 | const readFile = require("util").promisify(require("fs").readFile); 6 | const writeFile = require("util").promisify(require("fs").writeFile); 7 | 8 | const specVersion = require("./get-version.js"); 9 | 10 | const replaceVersionComments = s => s.replace("", `Version ${specVersion}`); 11 | 12 | const build = async () => { 13 | const buildDir = "./build/markdown/"; 14 | await fsx.ensureDir(buildDir); 15 | await fsx.emptyDir(buildDir); 16 | const specContent = await readFile("./spec.md", "utf8"); 17 | const withToc = toc.insert(specContent); 18 | const withVersion = replaceVersionComments(withToc); 19 | await writeFile(`${buildDir}/spec.md`, withVersion); 20 | 21 | console.log("building markdown complete. Markdown is ready to be released!"); 22 | 23 | return true; 24 | }; 25 | 26 | if (require.main === module) { 27 | build(); 28 | } else { 29 | module.exports = build; 30 | } 31 | -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "open-rpc-spec", 3 | "version": "1.3.2", 4 | "description": "The OPEN-RPC Specification", 5 | "main": "index.js", 6 | "private": true, 7 | "scripts": { 8 | "validate": "node_modules/.bin/mdv ./spec.md ./README.md ./build/markdown/*.md", 9 | "lint": "./node_modules/.bin/markdownlint ./spec.md ./README.md ./build/markdown/*.md", 10 | "build": "./bin/build.sh", 11 | "test": "npm run build && npm run validate && npm run lint" 12 | }, 13 | "repository": { 14 | "type": "git", 15 | "url": "git+https://github.com/open-rpc/spec.git" 16 | }, 17 | "keywords": [ 18 | "open-rpc", 19 | "rpc", 20 | "json-rpc", 21 | "api", 22 | "spec" 23 | ], 24 | "author": "Zachary Belford", 25 | "license": "Apache-2.0", 26 | "bugs": { 27 | "url": "https://github.com/open-rpc/spec/issues" 28 | }, 29 | "homepage": "https://github.com/open-rpc/spec#readme", 30 | "devDependencies": { 31 | "@etclabscore/dl-github-releases": "^1.2.1", 32 | "fs-extra": "^9.1.0", 33 | "markdown-toc": "^1.2.0", 34 | "markdownlint-cli": "^0.39.0", 35 | "mdv": "^1.3.2", 36 | "mkdirp": "^1.0.4" 37 | } 38 | } 39 | -------------------------------------------------------------------------------- /.releaserc: -------------------------------------------------------------------------------- 1 | { 2 | "tagFormat": "${version}", 3 | "branch": "master", 4 | "plugins": [ 5 | "@semantic-release/commit-analyzer", 6 | "@semantic-release/release-notes-generator", 7 | "@semantic-release/changelog", 8 | "@semantic-release/github", 9 | "@semantic-release/git", 10 | "@semantic-release/npm" 11 | ], 12 | "verifyConditions": [ 13 | "@semantic-release/changelog", 14 | "@semantic-release/git", 15 | "@semantic-release/github" 16 | ], 17 | "prepare": [ 18 | "@semantic-release/changelog", 19 | "@semantic-release/npm", 20 | [ 21 | "@semantic-release/exec", 22 | { 23 | "prepareCmd": "./bin/build.sh" 24 | } 25 | ], 26 | "@semantic-release/git" 27 | ], 28 | "publish": [ 29 | ["@semantic-release/github", { 30 | "assets": ["build/markdown/spec.md"] 31 | }], 32 | { 33 | "path": "@qiwi/semantic-release-gh-pages-plugin", 34 | "msg": "github pages release", 35 | "src": "build/ghpages/", 36 | "branch": "gh-pages" 37 | } 38 | ], 39 | "success": [ 40 | "@semantic-release/github" 41 | ], 42 | "fail": [ 43 | "@semantic-release/github" 44 | ] 45 | } 46 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # The OpenRPC Specification Repository 2 | 3 |

4 | open-rpc logo 5 |

6 | 7 |

8 | Join us on Discord! 9 |

10 | 11 | ## Purpose of this Repository 12 | 13 | This is a repository that contains the OpenRPC specification, and the tooling to build, maintain, and release the specification. 14 | 15 | ## Latest OpenRPC Specification 16 | 17 | The latest version of the specification may be found [here](https://spec.open-rpc.org/). 18 | 19 | ## Previous Versions of the Specification 20 | 21 | All versions of the specification can be found on [the Github releases page](https://github.com/open-rpc/spec/releases). 22 | 23 | You may also access specific versions of the spec by appending the version to the spec url as follows: 24 | 25 | `https://spec.open-rpc.org/1.0.0` 26 | 27 | ## Contributing 28 | 29 | How to contribute, build and release are outlined in [CONTRIBUTING.md](CONTRIBUTING.md), [BUILDING.md](BUILDING.md) and [RELEASING.md](RELEASING.md) respectively. Commits in this repository follow the [CONVENTIONAL_COMMITS.md](CONVENTIONAL_COMMITS.md) specification. 30 | 31 | ## Contact 32 | 33 | Need help or have a question? Join us on [Discord](https://discord.gg/gREUKuF)! 34 | -------------------------------------------------------------------------------- /VERSIONING.md: -------------------------------------------------------------------------------- 1 | # Versioning 2 | 3 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://tools.ietf.org/html/bcp14) [RFC2119](https://tools.ietf.org/html/rfc2119) [RFC8174](https://tools.ietf.org/html/rfc8174) when, and only when, they appear in all capitals, as shown here. 4 | 5 | This document is licensed under [The Apache License, Version 2.0](https://www.apache.org/licenses/LICENSE-2.0.html). 6 | 7 | ## Introduction 8 | This document is to describe how a project is to version its releases 9 | 10 | It also describes standardized tooling around manipulating the version 11 | 12 | ## Semver 13 | A project MUST use Semantic Versioning [semver](https://semver.org). Build metadata MAY NOT be used in a project. Build metadata SHOULD be ignored. 14 | 15 | A Basic summary of Semantic Versioning taken from: [semver.org](https://semver.org) 16 | 17 | ### Summary: 18 | 19 | Given a version number MAJOR.MINOR.PATCH, increment the: 20 | 21 | MAJOR version when you make incompatible API changes, 22 | MINOR version when you add functionality in a backwards-compatible manner, and 23 | PATCH version when you make backwards-compatible bug fixes. 24 | Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. 25 | -------------------------------------------------------------------------------- /.circleci/config.yml: -------------------------------------------------------------------------------- 1 | version: 2 2 | 3 | aliases: 4 | # ------------------------- 5 | # ALIASES: Caches 6 | # ------------------------- 7 | - &restore-deps-cache 8 | key: deps-cache-{{ checksum "package.json" }} 9 | 10 | - &save-deps-cache 11 | key: deps-cache-{{ checksum "package.json" }} 12 | paths: 13 | - ~/spec/node_modules 14 | 15 | # ------------------------- 16 | # ALIASES: Branch Filters 17 | # ------------------------- 18 | - &filter-only-master 19 | branches: 20 | only: master 21 | - &filter-only-semantic-pr 22 | branches: 23 | only: /^(pull|dependabot|fix|feat)\/.*$/ 24 | - &filter-only-fork-pr 25 | branches: 26 | only: /^pull\/.*$/ 27 | 28 | defaults: &defaults 29 | working_directory: ~/spec 30 | docker: 31 | - image: cimg/node:18.13.0 32 | 33 | jobs: 34 | test: 35 | <<: *defaults 36 | steps: 37 | - checkout 38 | - restore_cache: *restore-deps-cache 39 | - run: npm install 40 | - run: npm test 41 | - run: npm run build 42 | - save_cache: *save-deps-cache 43 | 44 | release: 45 | <<: *defaults 46 | steps: 47 | - checkout 48 | - restore_cache: *restore-deps-cache 49 | - run: npm install 50 | - run: npm test 51 | - run: rm -rf build 52 | - run: npm install semantic-release @semantic-release/changelog @semantic-release/git @semantic-release/github @semantic-release/npm @semantic-release/commit-analyzer @semantic-release/release-notes-generator @qiwi/semantic-release-gh-pages-plugin @semantic-release/exec 53 | - run: git checkout package.json package-lock.json 54 | - run: ./node_modules/.bin/semantic-release 55 | - save_cache: *save-deps-cache 56 | 57 | workflows: 58 | version: 2 59 | analysis: 60 | jobs: 61 | - test: 62 | filters: *filter-only-semantic-pr 63 | 64 | release: 65 | jobs: 66 | - test: 67 | filters: *filter-only-master 68 | - hold: 69 | filters: *filter-only-master 70 | type: approval 71 | requires: 72 | - test 73 | - release: 74 | filters: *filter-only-master 75 | context: open-rpc-deployer 76 | requires: 77 | - hold 78 | -------------------------------------------------------------------------------- /bin/build.ghpages.sh: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env node 2 | 3 | const {promisify} = require("util"); 4 | const downloadReleases = require('@etclabscore/dl-github-releases').default; 5 | const fs = require("fs"); 6 | const mkdir = promisify(fs.mkdir); 7 | const copyFile = promisify(fs.copyFile); 8 | const writeFile = promisify(fs.writeFile); 9 | const readdir = promisify(fs.readdir); 10 | const fsx = require("fs-extra"); 11 | const buildMarkdown = require("./build.markdown.sh"); 12 | const specVersion = require("./get-version.js"); 13 | 14 | const leaveZipped = false; 15 | const disableLogging = false; 16 | const filterRelease = (release) => { 17 | return true; 18 | } 19 | const filterAsset = (asset) => { 20 | return asset.name.indexOf('.md') >= 0; 21 | } 22 | 23 | const build = async () => { 24 | const buildDir = "./build/ghpages"; 25 | 26 | await fsx.ensureDir(buildDir); 27 | await fsx.emptyDir(buildDir); 28 | 29 | await downloadReleases("open-rpc", "spec", buildDir, filterRelease, filterAsset, leaveZipped, disableLogging); 30 | 31 | const previousVersions = await readdir(buildDir); 32 | 33 | await Promise.all(previousVersions.map(async (version) => { 34 | const dirName = `${buildDir}/${version}`; 35 | const [filename] = await readdir(dirName); 36 | await fsx.move(`${dirName}/${filename}`, `${dirName}/index.md`); 37 | })); 38 | 39 | 40 | 41 | await buildMarkdown(); 42 | const markdownBuildFilename = "./build/markdown/spec.md"; 43 | let latestVersionFolderName = `${buildDir}/${specVersion}`; 44 | 45 | await mkdir(`${buildDir}/latest`); 46 | try { 47 | await mkdir(latestVersionFolderName); 48 | } catch (e) { 49 | console.log(`latest version already exists as a release on github: ${latestVersionFolderName}`); 50 | latestVersionFolderName = `${buildDir}/development`; 51 | await mkdir(latestVersionFolderName); 52 | } 53 | await copyFile(markdownBuildFilename, `${buildDir}/index.md`); 54 | await copyFile(markdownBuildFilename, `${buildDir}/latest/index.md`); 55 | await copyFile("./build/markdown/spec.md", `${latestVersionFolderName}/spec.md`); 56 | 57 | await writeFile(`${buildDir}/CNAME`, "spec.open-rpc.org"); 58 | 59 | console.log("building ghpages complete. gh-pages build ready to release!"); 60 | }; 61 | 62 | if (require.main === module) { 63 | build(); 64 | } else { 65 | module.exports = build; 66 | } 67 | -------------------------------------------------------------------------------- /RELEASING.md: -------------------------------------------------------------------------------- 1 | # Releasing 2 | 3 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://tools.ietf.org/html/bcp14) [RFC2119](https://tools.ietf.org/html/rfc2119) [RFC8174](https://tools.ietf.org/html/rfc8174) when, and only when, they appear in all capitals, as shown here. 4 | 5 | This document is licensed under [The Apache License, Version 2.0](https://www.apache.org/licenses/LICENSE-2.0.html). 6 | 7 | When using the name 'version' we mean the versioning scheme described in [VERSIONING.md](VERSIONING.md) 8 | 9 | ## Introduction 10 | 11 | This document is to describe the release pipeline, which is taking the result of the artifacts created according to [BUILDING.md](BUILDING.md) and publish a release to the various release targets for the project. 12 | 13 | We propose: 14 | - a set of release targets that are allowable 15 | - a pipeline for handling the release folder's artifacts 16 | 17 | It is NOT the purpose of this document to describe how a project might create a build, NOR is it describing a strcture in which projects MUST write build artifacts to. It is describing the structure of the releases themselves. 18 | 19 | ## Release Pipeline 20 | 21 | ### Create a build from current branch 22 | 23 | Process is outlined in [BUILDING.md](BUILDING.md) 24 | 25 | 1. Clean the build directory 26 | 2. run: `bin/build.{target}.{ext}` 27 | 28 | ### Bump the version of the project 29 | 30 | Projects SHOULD automated the version bump following [CONVENTIONAL_COMMITS.md](CONVENTIONAL_COMMITS.md). 31 | 32 | ### Generate Changelog 33 | 34 | Projects SHOULD use generated changelogs from following [CONVENTIONAL_COMMITS.md](CONVENTIONAL_COMMITS.md). 35 | 36 | ### Commit the bump + changelog update 37 | 38 | A project MUST generate a commit with the changes. 39 | 40 | ### Tag the commit with the bumped version 41 | 42 | A project MUST be tagged with the semantic versioning scheme from [VERSIONING.md](VERSIONING.md). 43 | 44 | ### Sign the releases. 45 | 46 | - MUST be a pgp signature 47 | - MUST be the same pgp key as is registered with Github 48 | - MUST be a detached ascii-armored (.asc) signature 49 | - All files in the build folder MUST have an associated signature file 50 | 51 | ### Push changelog & version bump 52 | 53 | ### Run Release Targets 54 | 55 | For each of the desired release targets, prepare and push the release. 56 | 57 | #### Example Release Targets 58 | 59 | 1. Github 60 | 2. Docker Hub 61 | 62 | ## Resources 63 | 64 | - [semantic-release](https://github.com/semantic-release/semantic-release) 65 | - [Conventional Commits](https://conventionalcommits.org/ 66 | -------------------------------------------------------------------------------- /BUILDING.md: -------------------------------------------------------------------------------- 1 | # Building 2 | 3 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://tools.ietf.org/html/bcp14) [RFC2119](https://tools.ietf.org/html/rfc2119) [RFC8174](https://tools.ietf.org/html/rfc8174) when, and only when, they appear in all capitals, as shown here. 4 | 5 | This document is licensed under [The Apache License, Version 2.0](https://www.apache.org/licenses/LICENSE-2.0.html). 6 | 7 | When using the name 'version' we mean the versioning scheme described in [VERSIONING.md](VERSIONING.md) 8 | 9 | ## Introduction 10 | 11 | This document is to describe the functionality a project MUST provide in terms of creating build artifacts. It also describes the structure in which project's MUST write build artifacts in. 12 | 13 | A project MUST provide: 14 | 15 | - a folder name convention for build artifacts 16 | - a folder structure for the above-mentioned build artifacts folder 17 | - a list of targets 18 | - a file called `bin/build.{target}.{ext}` to target each of the build targets 19 | - a build pipeline given the above pretext 20 | 21 | The purpose of having a uniform way of producing a build is that we may ALL produce builds for any of the projects, making the onramp for new developers less steep, while still maintaining an exceptionally high level of quality. 22 | 23 | The projects should follow the 'architecture as code' principle - and should require a very minimal set of dependencies. 24 | 25 | It is the responsibilty of the build tooling to write artifacts to the appropriate location as outlined in this specification. 26 | 27 | ## Build Folder Name 28 | 29 | The cannonical folder for builds SHALL be named `build` and be located at the root of the project repository. 30 | Each project MUST `git ignore` the `build` folder. 31 | 32 | ## Build Folder Structure 33 | 34 | Files and folder names MUST be lowercase. 35 | The result of the build process should create a folder structure as follows: 36 | 37 | ``` 38 | . 39 | └── build 40 | └── {target} 41 | └── {project-name}.{ext} 42 | ``` 43 | 44 | 45 | Below is an example: 46 | ``` 47 | . 48 | └── build 49 | └── windows 50 | └── my-build.exe 51 | ``` 52 | 53 | ## Build Targets 54 | 55 | Below is a list of suggested targets for a project 56 | 1. windows 57 | 2. linux 58 | 3. macos 59 | 60 | ## Build script 61 | 62 | Each release target MUST have a `bin/build.{target}.{ext}` file. 63 | 64 | The result of this is that every project MUST produce a build for each target when the following command is invoked: 65 | 66 | ``` 67 | bin/build.{target}.{ext}` 68 | ``` 69 | 70 | The file MUST be placed in the project's `bin` directory. 71 | 72 | ## Build Pipeline 73 | 74 | ### Building targets 75 | 76 | `bin/build.{target}.{ext}` should create builds for each of the targets, and place the build artifacts in a folder structure outlined above. 77 | 78 | ### Windows 79 | 80 | ``` 81 | bin/build.windows.bat 82 | ``` 83 | 84 | ### Linux 85 | 86 | ``` 87 | bin/build.linux.sh 88 | ``` 89 | 90 | ### Macos 91 | 92 | ``` 93 | bin/build.macos.sh 94 | ``` 95 | -------------------------------------------------------------------------------- /FAQ.md: -------------------------------------------------------------------------------- 1 | 2 | ### Are there assets I can use to talk about OpenRPC? 3 | 4 | [open-rpc/design](https://github.com/open-rpc/design/) houses all the design assets for OpenRPC 5 | 6 | ![openrpc-spec-structure](https://github.com/open-rpc/design/raw/master/diagrams/structure/OpenRPC_structure.png) 7 | ![openrpc-logo](https://github.com/open-rpc/design/raw/master/png/open-rpc-logo-320x320.png) 8 | 9 | ### Why should I use OpenRPC to describe my JSON-RPC API? 10 | 11 | OpenRPC documents are both machine and human readable and clearly define your API. 12 | Use cases for machine-readable JSON-RPC API definition documents include, but are not limited to: 13 | - interactive documentation 14 | - code generation for documentation 15 | - clients 16 | - servers 17 | - mock servers 18 | - automation of test cases 19 | - improve maintainability 20 | - reduce code and mistakes 21 | - parallel teams building of client/server based on the agreed spec 22 | 23 | ### Why JSON-RPC? 24 | 25 | [REST is pretty ambiguous](https://www.nurkiewicz.com/2015/07/restful-considered-harmful.html). It is unlikely that any two developers will produce the same REST API. JSON-RPC is a serious contender for services because it is simple, JSON based, and protocol agnostic. 26 | 27 | There is a growing need for a standard way to describe the critical open source infrastructure that depends on it. 28 | 29 | ### Is there anywhere I can try OpenRPC? 30 | 31 | Yes, you can experiment with OpenRPC using our [Playground](https://playground.open-rpc.org/) tool. There are pre-built examples in playground that can be used for learning and reference. 32 | 33 | ### What uses JSON-RPC in the wild? 34 | 35 | - [Bitcoin](https://en.bitcoinwiki.org/wiki/JSON-RPC) 36 | - [Ethereum Classic](https://github.com/ethereumproject/wiki/wiki/JSON-RPC) 37 | - [Ethereum](https://github.com/ethereum/wiki/wiki/JSON-RPC) 38 | - [Tezos](https://tezos.gitlab.io/alphanet/tutorials/rpc.html) 39 | - [Monero](https://github.com/monero-project/monero) 40 | - [Qtum](https://qtumproject.github.io/qtumjs-doc/) 41 | - [Quorum](https://github.com/jpmorganchase/quorum) 42 | - [Zcash](https://github.com/zcash/zcash) 43 | - [Ripple](https://developers.ripple.com/get-started-with-the-rippled-api.html) 44 | - [Litecoin](https://github.com/litecoin-project/litecoin) 45 | - [Dash](https://github.com/dashpay/dash) 46 | - [Dogecoin](https://github.com/dogecoin/dogecoin) 47 | - [Visual Studio Language Server Extensions](https://code.visualstudio.com/api/language-extensions/language-server-extension-guide) 48 | - [Microsoft Language Server](https://docs.microsoft.com/en-us/visualstudio/extensibility/language-server-protocol?view=vs-2017) 49 | - [Microsoft SQL Tools Service](https://github.com/Microsoft/sqltoolsservice/) 50 | - [Kodi](https://kodi.wiki/view/JSON-RPC_API) 51 | - [OpenDaylight](https://www.opendaylight.org/) 52 | - [RANDOM.ORG](https://api.random.org/json-rpc/1/) 53 | - [FreeIPA](https://www.freeipa.org) 54 | - [PPIO](https://www.pp.io) 55 | - [Tarantool](https://github.com/tarantool/nginx_upstream_module) 56 | 57 | ### Is the specification available in languages other than English? 58 | 59 | Currently the specification does not support any languages other than English. However, we are considering possible solutions 60 | to the situation. If you wish to follow or contribute to the discussion it can be found [here](https://github.com/open-rpc/spec/issues/252). 61 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing 2 | 3 | > This document is inspired by [elasticsearch/CONTRIBUTING.md](https://github.com/elastic/elasticsearch/blob/master/CONTRIBUTING.md) 4 | 5 | Adding a `CONTRIBUTING.md` to a Github repository enables a link to that file in the pull request or create an issue page. This document should guide potential contributors toward making a successful and meaningful impact on the project, and can save maintainers time and hassle caused by improper pull requests and issues. You can learn more about the features that are enabled by Github when this file is present [here](https://help.github.com/articles/setting-guidelines-for-repository-contributors/). 6 | 7 | ## How to contribute 8 | 9 | There are many ways to contribute, from writing tutorials or blog posts, improving the documentation, [submitting Github issues](https://help.github.com/articles/creating-an-issue/), bug reports, feature requests and writing code. 10 | 11 | ## License 12 | 13 | This repository uses the [The Apache License, Version 2.0](https://www.apache.org/licenses/LICENSE-2.0.html). 14 | 15 | ## Bug reports 16 | 17 | If you think you've found a bug in the software, first make sure you're testing against the *latest* version of the software -- your issue may have been fixed already. If it's not, please check out the issues list on Github and search for similar issues that have already been opened. If there are no issues then please [submit a Github issue](https://help.github.com/articles/creating-an-issue/). 18 | 19 | If you can provide a small test case it would greatly help the reproduction of a bug, as well as a a screenshot, and any other information you can provide. 20 | 21 | 22 | ## Feature Requests 23 | 24 | If there are features that do not exist yet, we are definitely open to feature requests and detailed proposals. [Open an issue](https://help.github.com/articles/creating-an-issue/) on our Github which describes the feature or proposal in detail, answer questions like why? how? 25 | 26 | ## Contributing Code and Documentation Changes 27 | 28 | Bug fixes, patches and new features are welcome. Please find or open an issue about it first. Talk about what exactly want to do, someone may already be working on it, or there might be some issues that you need to be aware of before implementing the fix. 29 | 30 | There are many ways to fix a problem and it is important to find the best approach before writing a ton of code. 31 | 32 | ##### Documentation Changes 33 | 34 | For small documentation changes and fixes, these can be done quickly following this video guide on [how to contribute to Open Source in 1 minute on Github](https://www.youtube.com/watch?v=kRYk1-yKwWs). 35 | 36 | ### Forking the repository 37 | 38 | [How to fork a repository](https://help.github.com/articles/fork-a-repo/). 39 | 40 | ### Submitting changes 41 | 42 | 1. Review & Test changes 43 | * If the code changed, then test it. If documentation changed, then preview the rendered Markdown. 44 | 2. Commiting 45 | * Follow the [Convention Commits](CONVENTIONAL_COMMITS.md) guidelines to create a commit message 46 | 3. Sign the CLA 47 | * Make sure you've signed the repository's Contributor License Agreement. We are not asking you to assign copyright to us, but to give us the right to distribute your code without restriction. We ask this of all contributors in order to assure our users of the origin and continuing existence of the code. You only need to sign the CLA once. 48 | 4. Submit a pull request 49 | * Push local changes to your forked repository and make a pull request. Follow the [Convention Commits](CONVENTIONAL_COMMITS.md) guidelines for naming Github pull requests and what to put in the body. 50 | 51 | 52 | ## Building 53 | 54 | Follow the build process is outlined in [BUILDING.md](BUILDING.md) to create a build. 55 | 56 | 57 | ## Releasing 58 | 59 | Follow the release process is outlined in [RELEASING.md](RELEASING.md) to create a release. 60 | 61 | 62 | -------------------------------------------------------------------------------- /CONVENTIONAL_COMMITS.md: -------------------------------------------------------------------------------- 1 | # Conventional Commits 1.0.0-beta.2 2 | 3 | > This spec is a direct copy from [http://conventionalcommits.org](http://conventionalcommits.org). It lives here as a reference document for new contributors. 4 | 5 | ## Summary 6 | 7 | The [Conventional Commits](http://conventionalcommits.org) specification is a lightweight convention on top of commit messages. 8 | It provides an easy set of rules for creating an explicit commit history; 9 | which makes it easier to write automated tools on top of. 10 | This convention dovetails with [SemVer](http://semver.org), 11 | by describing the features, fixes, and breaking changes made in commit messages. 12 | 13 | The commit message should be structured as follows: 14 | 15 | --- 16 | 17 | ``` 18 | [optional scope]: 19 | 20 | [optional body] 21 | 22 | [optional footer] 23 | ``` 24 | --- 25 | 26 |
27 | The commit contains the following structural elements, to communicate intent to the 28 | consumers of your library: 29 | 30 | 1. **fix:** a commit of the _type_ `fix` patches a bug in your codebase (this correlates with [`PATCH`](http://semver.org/#summary) in semantic versioning). 31 | 1. **feat:** a commit of the _type_ `feat` introduces a new feature to the codebase (this correlates with [`MINOR`](http://semver.org/#summary) in semantic versioning). 32 | 1. **BREAKING CHANGE:** a commit that has the text `BREAKING CHANGE:` at the beginning of its optional body or footer section introduces a breaking API change (correlating with [`MAJOR`](http://semver.org/#summary) in semantic versioning). 33 | A BREAKING CHANGE can be part of commits of any _type_. 34 | 1. Others: commit _types_ other than `fix:` and `feat:` are allowed, for example [commitlint-config-conventional](https://github.com/marionebl/commitlint/tree/master/%40commitlint/config-conventional) (based on the [the Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) recommends `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, and others. 35 | We also recommend `improvement` for commits that improve a current implementation without adding a new feature or fixing a bug. 36 | Notice these types are not mandated by the conventional commits specification, and have no implicit effect in semantic versioning (unless they include a BREAKING CHANGE). 37 |
38 | A scope may be provided to a commit's type, to provide additional contextual information and is contained within parenthesis, e.g., `feat(parser): add ability to parse arrays`. 39 | 40 | ## Examples 41 | 42 | ### Commit message with description and breaking change in body 43 | ``` 44 | feat: allow provided config object to extend other configs 45 | 46 | BREAKING CHANGE: `extends` key in config file is now used for extending other config files 47 | ``` 48 | 49 | ### Commit message with no body 50 | ``` 51 | docs: correct spelling of CHANGELOG 52 | ``` 53 | 54 | ### Commit message with scope 55 | ``` 56 | feat(lang): added polish language 57 | ``` 58 | 59 | ### Commit message for a fix using an (optional) issue number. 60 | ``` 61 | fix: minor typos in code 62 | 63 | see the issue for details on the typos fixed 64 | 65 | fixes issue #12 66 | ``` 67 | ## Specification 68 | 69 | The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). 70 | 71 | 1. Commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc., followed by a colon and a space. 72 | 1. The type `feat` MUST be used when a commit adds a new feature to your application or library. 73 | 1. The type `fix` MUST be used when a commit represents a bug fix for your application. 74 | 1. An optional scope MAY be provided after a type. A scope is a phrase describing a section of the codebase enclosed in parenthesis, e.g., `fix(parser):` 75 | 1. A description MUST immediately follow the type/scope prefix. 76 | The description is a short description of the code changes, e.g., _fix: array parsing issue when multiple spaces were contained in string._ 77 | 1. A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description. 78 | 1. A footer MAY be provided one blank line after the body. 79 | The footer SHOULD contain additional issue references about the code changes (such as the issues it fixes, e.g.,`Fixes #13`). 80 | 1. Breaking changes MUST be indicated at the very beginning of the footer or body section of a commit. A breaking change MUST consist of the uppercase text `BREAKING CHANGE`, followed by a colon and a space. 81 | 1. A description MUST be provided after the `BREAKING CHANGE: `, describing what has changed about the API, e.g., _BREAKING CHANGE: environment variables now take precedence over config files._ 82 | 1. The footer MUST only contain `BREAKING CHANGE`, external links, issue references, and other meta-information. 83 | 1. Types other than `feat` and `fix` MAY be used in your commit messages. 84 | 85 | ## Why Use Conventional Commits 86 | 87 | * Automatically generating CHANGELOGs. 88 | * Automatically determining a semantic version bump (based on the types of commits landed). 89 | * Communicating the nature of changes to teammates, the public, and other stakeholders. 90 | * Triggering build and publish processes. 91 | * Making it easier for people to contribute to your projects, by allowing them to explore 92 | a more structured commit history. 93 | 94 | ## FAQ 95 | 96 | ### How should I deal with commit messages in the initial development phase? 97 | 98 | We recommend that you proceed as if you've an already released product. Typically *somebody*, even if its your fellow software developers, is using your software. They'll want to know what's fixed, what breaks etc. 99 | 100 | ### Are the types in the commit title uppercase or lowercase? 101 | 102 | Any casing may be used, but it's best to be consistent. 103 | 104 | ### What do I do if the commit conforms to more than one of the commit types? 105 | 106 | Go back and make multiple commits whenever possible. Part of the benefit of Conventional Commits is its ability to drive us to make more organized commits and PRs. 107 | 108 | ### Doesn’t this discourage rapid development and fast iteration? 109 | 110 | It discourages moving fast in a disorganized way. It helps you be able to move fast long term across multiple projects with varied contributors. 111 | 112 | ### Might Conventional Commits lead developers to limit the type of commits they make because they'll be thinking in the types provided? 113 | 114 | Conventional Commits encourages us to make more of certain types of commits such as fixes. Other than that, the flexibility of Conventional Commits allows your team to come up with their own types and change those types over time. 115 | 116 | ### How does this relate to SemVer? 117 | 118 | `fix` type commits should be translated to `PATCH` releases. `feat` type commits should be translated to `MINOR` releases. Commits with `BREAKING CHANGE` in the commits, regardless of type, should be translated to `MAJOR` releases. 119 | 120 | ### How should I version my extensions to the Conventional Commits Specification, e.g. `@jameswomack/conventional-commit-spec`? 121 | 122 | We recommend using SemVer to release your own extensions to this specification (and 123 | encourage you to make these extensions!) 124 | 125 | ### What do I do if I accidentally use the wrong commit type? 126 | 127 | #### When you used a type that's of the spec but not the correct type, e.g. `fix` instead of `feat` 128 | 129 | Prior to merging or releasing the mistake, we recommend using `git rebase -i` to edit the commit history. After release, the cleanup will be different according to what tools and processes you use. 130 | 131 | #### When you used a type *not* of the spec, e.g. `feet` instead of `feat` 132 | 133 | In a worst case scenario, it's not the end of the world if a commit lands that does not meet the conventional commit specification. It simply means that commit will be missed by tools that are based on the spec. 134 | 135 | ### Do all my contributors need to use the conventional commit specification? 136 | 137 | No! If you use a squash based workflow on Git lead maintainers can cleanup the commit messages as they're merged—adding no workload to casual committers. 138 | A common workflow for this is to have your git system automatically squash commits from a pull request and present a form for the lead maintainer to enter the proper git commit message for the merge. 139 | 140 | ## About 141 | 142 | The Conventional Commit specification is inspired by, and based heavily on, the [Angular Commit Guidelines](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines). 143 | 144 | The first draft of this specification has been written in collaboration with some of the folks contributing to: 145 | 146 | * [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog): a set of tools for parsing conventional commit messages from git histories. 147 | * [bumped](https://bumped.github.io): a tool for releasing software that makes it easy to perform actions before and after releasing a new version of your software. 148 | * [unleash](https://github.com/netflix/unleash): a tool for automating the software release and publishing lifecycle. 149 | * [lerna](https://github.com/lerna/lerna): a tool for managing monorepos, which grew out of the Babel project. 150 | 151 | ## Tooling for Conventional Commits 152 | 153 | * [conform](https://github.com/autonomy/conform): a tool that can be used to enforce policies on git repositories, including conventional commits. 154 | 155 | ## Projects Using Conventional Commits 156 | 157 | * [yargs](https://github.com/yargs/yargs): everyone's favorite pirate themed command line argument parser. 158 | * [istanbuljs](https://github.com/istanbuljs/istanbuljs): a collection of open-source tools and libraries for adding test coverage to your JavaScript tests. 159 | * [standard-version](https://github.com/conventional-changelog/standard-version): Automatic versioning and CHANGELOG management, using GitHub's new squash button and the recommended Conventional Commits workflow. 160 | * [uPortal-home](https://github.com/UW-Madison-DoIT/angularjs-portal) and [uPortal-application-framework](https://github.com/UW-Madison-DoIT/uw-frame): Optional supplemental user interface enhancing [Apereo uPortal](https://www.apereo.org/projects/uportal). 161 | * [massive.js](https://github.com/dmfay/massive-js): A data access library for Node and PostgreSQL. 162 | * [electron](https://github.com/electron/electron): Build cross-platform desktop apps with JavaScript, HTML, and CSS. 163 | * [scroll-utility](https://github.com/LeDDGroup/scroll-utility): A simple to use scroll utility package for centering elements, and smooth animations 164 | * [Blaze UI](https://github.com/BlazeUI/blaze): Framework-free open source modular toolkit. 165 | 166 | [![Conventional Commits](https://img.shields.io/badge/Conventional%20Commits-1.0.0-yellow.svg)](https://conventionalcommits.org) 167 | 168 | _want your project on this list?_ [send a pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls). 169 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /CHANGELOG.md: -------------------------------------------------------------------------------- 1 | ## [1.3.2](https://github.com/open-rpc/spec/compare/1.3.1...1.3.2) (2023-07-04) 2 | 3 | 4 | ### Bug Fixes 5 | 6 | * examplePairingObject.name and params are required in the metaschema ([3cdace9](https://github.com/open-rpc/spec/commit/3cdace9c208d2874d0b966c73687defc7ba40990)) 7 | 8 | ## [1.3.1](https://github.com/open-rpc/spec/compare/1.3.0...1.3.1) (2023-02-06) 9 | 10 | 11 | ### Bug Fixes 12 | 13 | * add a note about examplePairingObject.result being undefined ([30aee1b](https://github.com/open-rpc/spec/commit/30aee1b5186d623f197b4f31cb6152bc0bbd23c0)) 14 | * tests borked up ([5f73e6e](https://github.com/open-rpc/spec/commit/5f73e6e157b01b17a7790050c886e70957b4646a)) 15 | 16 | # [1.3.0](https://github.com/open-rpc/spec/compare/1.2.6...1.3.0) (2023-02-01) 17 | 18 | 19 | ### Bug Fixes 20 | 21 | * bump node version and update circle config ([52403aa](https://github.com/open-rpc/spec/commit/52403aabd8eb0a2a6cd52ecfe10d7e48b9b4dcde)) 22 | * dont point to latest json schema ([114202c](https://github.com/open-rpc/spec/commit/114202cf52ce1b0d196d816551aec2e64f0e4230)), closes [#330](https://github.com/open-rpc/spec/issues/330) 23 | * follow conventional capitalization pattern ([bb3b838](https://github.com/open-rpc/spec/commit/bb3b838d61f2c5c5cf194183ea6015d76e54bdb5)) 24 | * markdown inside html doenst work ([664eec1](https://github.com/open-rpc/spec/commit/664eec189eb19f684913b8517f82ab4c1a2b6bc1)) 25 | * missing bracket ([8f6e649](https://github.com/open-rpc/spec/commit/8f6e6497d45a5d15db1c389ff1cb1992334887fe)) 26 | * re-order release perparation steps ([4893ac8](https://github.com/open-rpc/spec/commit/4893ac88b623b6af188c500c7d6445734252aa2d)), closes [#292](https://github.com/open-rpc/spec/issues/292) 27 | * remove example object referencing content descriptor use ([b9f00de](https://github.com/open-rpc/spec/commit/b9f00de8d48494944b04762bca0095cfffab9b91)), closes [/github.com/open-rpc/spec/issues/315#issuecomment-718258896](https://github.com//github.com/open-rpc/spec/issues/315/issues/issuecomment-718258896) 28 | * s/supercedes/supersedes/ ([91533e3](https://github.com/open-rpc/spec/commit/91533e30e997581ba84c2966c500c30afb92d59b)) 29 | * shamelessly add funding link via open collective ([c3f8de2](https://github.com/open-rpc/spec/commit/c3f8de27cd85d19fd68e1e5fa65b8213e935ca88)) 30 | * typo in Example Object ([c551b21](https://github.com/open-rpc/spec/commit/c551b2128d40a333ed307ae7c608f065e77fe505)) 31 | * update discord link ([d75ceeb](https://github.com/open-rpc/spec/commit/d75ceeb6a8ee23fcb29e83993c4cb3e4016d745a)) 32 | * update labler to v4 ([cd3ac52](https://github.com/open-rpc/spec/commit/cd3ac52959f97ced96c7a7c38983e4b0771879e7)) 33 | 34 | 35 | ### Features 36 | 37 | * add support for strict notification methods ([a9a3091](https://github.com/open-rpc/spec/commit/a9a30917983c1efe417cd72825559896db19fbe1)), closes [#230](https://github.com/open-rpc/spec/issues/230) 38 | 39 | ## [1.2.6](https://github.com/open-rpc/spec/compare/1.2.5...1.2.6) (2020-05-22) 40 | 41 | 42 | ### Bug Fixes 43 | 44 | * schema required formatting ([1a745b5](https://github.com/open-rpc/spec/commit/1a745b51fd97fc4645d2ec2fd0196b634525ceec)) 45 | * **method.paramStructure:** add spec detailing by-name case of cd.name ([646978c](https://github.com/open-rpc/spec/commit/646978cb550cf336cce1bbad5634263b4f74d6c4)) 46 | * [@belfordz](https://github.com/belfordz) edits for awesomeness ([cbae9e3](https://github.com/open-rpc/spec/commit/cbae9e3165f28e3c9d716a23d76e0a1ac832844a)) 47 | * add another oxford comma ([b1092f6](https://github.com/open-rpc/spec/commit/b1092f699ed7d5f843eeaaccd181416087b1fc08)) 48 | * append 's' to param_s_ field ([9da993b](https://github.com/open-rpc/spec/commit/9da993be2644f8e2461d8daf2d408e9242cd634b)) 49 | * formatting of required on linkObject.name ([63f5410](https://github.com/open-rpc/spec/commit/63f5410217bb15f90ae7dc88a5f54b99cdc7f21c)) 50 | * missing oxford comma ([df8a507](https://github.com/open-rpc/spec/commit/df8a507327d513a4806aa5176bab9d474d813b4c)) 51 | * non-oxfordian missing space after oxfordian comma ([1deef5c](https://github.com/open-rpc/spec/commit/1deef5cffc69e3448bdd95a05ab92b50fd26bc13)) 52 | * remove oneOf ([215b0ae](https://github.com/open-rpc/spec/commit/215b0ae28ef6b7951f1e0d88fee904906da47d27)), closes [#278](https://github.com/open-rpc/spec/issues/278) 53 | * remove unused dev deps ([11df1e8](https://github.com/open-rpc/spec/commit/11df1e847c2de50f8d4b24fd996206b7c335a19b)) 54 | * s/field/value ([75275e6](https://github.com/open-rpc/spec/commit/75275e6cd7bd6980d01e4ad42904ea6d1cba2026)) 55 | * update FAQ and add to repo ([7c7310c](https://github.com/open-rpc/spec/commit/7c7310c3e660279ab4411680b5afb562bc7a3c84)), closes [#283](https://github.com/open-rpc/spec/issues/283) 56 | 57 | ## [1.2.5](https://github.com/open-rpc/spec/compare/1.2.4...1.2.5) (2020-05-06) 58 | 59 | 60 | ### Bug Fixes 61 | 62 | * default paramStructure to either ([558241f](https://github.com/open-rpc/spec/commit/558241fbb25cc59baaa0b3782078e9d4bc470467)), closes [#270](https://github.com/open-rpc/spec/issues/270) 63 | 64 | ## [1.2.4](https://github.com/open-rpc/spec/compare/1.2.3...1.2.4) (2019-12-20) 65 | 66 | 67 | ### Bug Fixes 68 | 69 | * set private to true in package json to avoid publishing ([1ff411a](https://github.com/open-rpc/spec/commit/1ff411af447d255705cde16d1f7f9cbcbeafebb7)) 70 | * version fix take 4 ([844eccc](https://github.com/open-rpc/spec/commit/844eccc31d475e55c39e006e05b7b0e9287983fd)) 71 | 72 | ## [1.2.3](https://github.com/open-rpc/spec/compare/1.2.2...1.2.3) (2019-12-20) 73 | 74 | 75 | ### Bug Fixes 76 | 77 | * missing run command ([b4144f9](https://github.com/open-rpc/spec/commit/b4144f9c464ca57cf64dacb34591405ef8cff8bb)) 78 | * second attempt at getting version fixed ([b12c828](https://github.com/open-rpc/spec/commit/b12c828426b1da52b4418f769c57af05c8950641)) 79 | * third attempt at fixing version ([9758c93](https://github.com/open-rpc/spec/commit/9758c9309ef71b8f024f70c52cd663b14a0e2449)) 80 | * update definitions and remove the word schema ([4577270](https://github.com/open-rpc/spec/commit/4577270379ed96985ba1d8c6fddbfd7349880446)) 81 | 82 | ## [1.2.2](https://github.com/open-rpc/spec/compare/1.2.1...1.2.2) (2019-12-20) 83 | 84 | 85 | ### Bug Fixes 86 | 87 | * restore package.json ([9e108bf](https://github.com/open-rpc/spec/commit/9e108bfb0c65931a817cf43774360bdf0c561fda)) 88 | * semantic-release fixups ([c8b33e5](https://github.com/open-rpc/spec/commit/c8b33e5adc2ead057cc6c59f3e4528b6d398c3ef)) 89 | * set version properly ([daf2a82](https://github.com/open-rpc/spec/commit/daf2a8234b7044bfe0bcc4e97dcfc251b4bd12fb)), closes [#191](https://github.com/open-rpc/spec/issues/191) 90 | * update build accordingly ([af8fe8d](https://github.com/open-rpc/spec/commit/af8fe8d8043736703e442ec73f70cc58edb9c2d6)) 91 | 92 | ## [1.2.1](https://github.com/open-rpc/spec/compare/1.2.0...1.2.1) (2019-09-26) 93 | 94 | 95 | ### Bug Fixes 96 | 97 | * add "either" option for param structure ([947c12b](https://github.com/open-rpc/spec/commit/947c12b)), closes [#190](https://github.com/open-rpc/spec/issues/190) [#226](https://github.com/open-rpc/spec/issues/226) 98 | 99 | # [1.2.0](https://github.com/open-rpc/spec/compare/1.1.12...1.2.0) (2019-09-23) 100 | 101 | 102 | ### Bug Fixes 103 | 104 | * checkout package after installing semanticrel ([a9d5841](https://github.com/open-rpc/spec/commit/a9d5841)) 105 | * remove additional dash ([0674aaf](https://github.com/open-rpc/spec/commit/0674aaf)) 106 | * remove sem rel deps last time ([5388f19](https://github.com/open-rpc/spec/commit/5388f19)) 107 | * remove sponsor ([85c83e1](https://github.com/open-rpc/spec/commit/85c83e1)) 108 | 109 | 110 | ### Features 111 | 112 | * add first set of labels ([5c86521](https://github.com/open-rpc/spec/commit/5c86521)) 113 | * add greetings action ([8bccaf3](https://github.com/open-rpc/spec/commit/8bccaf3)) 114 | * add labler action ([74b1909](https://github.com/open-rpc/spec/commit/74b1909)) 115 | 116 | ## [1.1.12](https://github.com/open-rpc/spec/compare/1.1.11...1.1.12) (2019-07-30) 117 | 118 | 119 | ### Bug Fixes 120 | 121 | * **circle:** add build ([4c3ae15](https://github.com/open-rpc/spec/commit/4c3ae15)) 122 | 123 | ## [1.1.11](https://github.com/open-rpc/spec/compare/1.1.10...1.1.11) (2019-07-30) 124 | 125 | 126 | ### Bug Fixes 127 | 128 | * install semantic release in circle ([641562f](https://github.com/open-rpc/spec/commit/641562f)) 129 | * remove semantic release from packagejson ([d799ce2](https://github.com/open-rpc/spec/commit/d799ce2)) 130 | * update package lock ([c6ecb2a](https://github.com/open-rpc/spec/commit/c6ecb2a)) 131 | 132 | ## [1.1.10](https://github.com/open-rpc/spec/compare/1.1.9...1.1.10) (2019-06-04) 133 | 134 | 135 | ### Bug Fixes 136 | 137 | * Require optional params to follow required params ([a031e71](https://github.com/open-rpc/spec/commit/a031e71)), closes [#188](https://github.com/open-rpc/spec/issues/188) 138 | 139 | ## [1.1.9](https://github.com/open-rpc/spec/compare/1.1.8...1.1.9) (2019-05-15) 140 | 141 | 142 | ### Bug Fixes 143 | 144 | * change type of MethodObject.name to string ([2282b29](https://github.com/open-rpc/spec/commit/2282b29)), closes [#180](https://github.com/open-rpc/spec/issues/180) 145 | * typo ([ef7b956](https://github.com/open-rpc/spec/commit/ef7b956)) 146 | * typo in a Map description ([247f298](https://github.com/open-rpc/spec/commit/247f298)) 147 | 148 | ## [1.1.8](https://github.com/open-rpc/spec/compare/1.1.7...1.1.8) (2019-04-27) 149 | 150 | 151 | ### Bug Fixes 152 | 153 | * **methodObject:** optional params recommendation ([5d614b2](https://github.com/open-rpc/spec/commit/5d614b2)), closes [#138](https://github.com/open-rpc/spec/issues/138) 154 | 155 | ## [1.1.7](https://github.com/open-rpc/spec/compare/1.1.6...1.1.7) (2019-04-23) 156 | 157 | 158 | ### Bug Fixes 159 | 160 | * add OneOf object to result ([d905538](https://github.com/open-rpc/spec/commit/d905538)), closes [#170](https://github.com/open-rpc/spec/issues/170) 161 | * release ([4544160](https://github.com/open-rpc/spec/commit/4544160)) 162 | 163 | ## [1.1.6](https://github.com/open-rpc/spec/compare/1.1.5...1.1.6) (2019-04-18) 164 | 165 | 166 | ### Bug Fixes 167 | 168 | * build filter get-version ([0fc9ef8](https://github.com/open-rpc/spec/commit/0fc9ef8)) 169 | * cleanup ([23a0ff4](https://github.com/open-rpc/spec/commit/23a0ff4)) 170 | * formatting ([e8aea3d](https://github.com/open-rpc/spec/commit/e8aea3d)) 171 | * make obvious that version isnt real ([e38cfc0](https://github.com/open-rpc/spec/commit/e38cfc0)) 172 | * release version templated ([141d4e3](https://github.com/open-rpc/spec/commit/141d4e3)) 173 | * **toc:** build working again ([5ae4e66](https://github.com/open-rpc/spec/commit/5ae4e66)) 174 | * remove build from ci ([2dbe3f9](https://github.com/open-rpc/spec/commit/2dbe3f9)) 175 | * update scripts ([9f13be6](https://github.com/open-rpc/spec/commit/9f13be6)) 176 | * versioned latest url ([ff4bcc8](https://github.com/open-rpc/spec/commit/ff4bcc8)) 177 | 178 | ## [1.1.5](https://github.com/open-rpc/spec/compare/1.1.4...1.1.5) (2019-04-08) 179 | 180 | 181 | ### Bug Fixes 182 | 183 | * **release:** try again ([7ba538d](https://github.com/open-rpc/spec/commit/7ba538d)) 184 | 185 | ## [1.1.4](https://github.com/open-rpc/spec/compare/1.1.3...1.1.4) (2019-04-08) 186 | 187 | 188 | ### Bug Fixes 189 | 190 | * gitignore build properly ([b2eb08d](https://github.com/open-rpc/spec/commit/b2eb08d)) 191 | * release plugins ([8050a74](https://github.com/open-rpc/spec/commit/8050a74)) 192 | * remove build folder ([b02fe72](https://github.com/open-rpc/spec/commit/b02fe72)) 193 | 194 | ## [1.1.2](https://github.com/open-rpc/spec/compare/1.1.1...1.1.2) (2019-04-08) 195 | 196 | 197 | ### Bug Fixes 198 | 199 | * release not uploading artifacts ([6a9c721](https://github.com/open-rpc/spec/commit/6a9c721)) 200 | 201 | ## [1.1.1](https://github.com/open-rpc/spec/compare/1.1.0...1.1.1) (2019-04-08) 202 | 203 | 204 | ### Bug Fixes 205 | 206 | * add success and fail handler to release ([589db49](https://github.com/open-rpc/spec/commit/589db49)) 207 | * **release:** indicate commit messages generated ([8c34567](https://github.com/open-rpc/spec/commit/8c34567)) 208 | * **releaserc:** tighten commit message sign off ([b06a454](https://github.com/open-rpc/spec/commit/b06a454)) 209 | 210 | # [1.1.0](https://github.com/open-rpc/spec/compare/1.0.0...1.1.0) (2019-04-07) 211 | 212 | 213 | ### Bug Fixes 214 | 215 | * gh release artifact name ([a38601d](https://github.com/open-rpc/spec/commit/a38601d)) 216 | 217 | 218 | ### Features 219 | 220 | * add link for latest version of spec ([ce8ecf0](https://github.com/open-rpc/spec/commit/ce8ecf0)) 221 | 222 | # 1.0.0 (2019-04-01) 223 | 224 | 225 | ### Bug Fixes 226 | 227 | * add alt to logo ([37898f3](https://github.com/open-rpc/spec/commit/37898f3)) 228 | * add description for contentDescriptors ([e65b691](https://github.com/open-rpc/spec/commit/e65b691)) 229 | * add empty job ([0691234](https://github.com/open-rpc/spec/commit/0691234)) 230 | * add error to method ([a12b656](https://github.com/open-rpc/spec/commit/a12b656)) 231 | * add example in schema case ([5e61cca](https://github.com/open-rpc/spec/commit/5e61cca)) 232 | * add extra explanation ([791cf11](https://github.com/open-rpc/spec/commit/791cf11)) 233 | * add info about examples and meta schema ([8623dea](https://github.com/open-rpc/spec/commit/8623dea)) 234 | * add markdownlint ([ea6994b](https://github.com/open-rpc/spec/commit/ea6994b)), closes [#148](https://github.com/open-rpc/spec/issues/148) 235 | * add name and summary to Link Object ([cafd56b](https://github.com/open-rpc/spec/commit/cafd56b)), closes [#127](https://github.com/open-rpc/spec/issues/127) 236 | * add pairing name ([299d523](https://github.com/open-rpc/spec/commit/299d523)) 237 | * add param structure field to support json rpc accurately ([e848fe6](https://github.com/open-rpc/spec/commit/e848fe6)) 238 | * add required to errorObject fields ([8d295de](https://github.com/open-rpc/spec/commit/8d295de)), closes [#104](https://github.com/open-rpc/spec/issues/104) 239 | * add video guide for making small documentation changes ([687692d](https://github.com/open-rpc/spec/commit/687692d)) 240 | * always use examples as array ([9c31f53](https://github.com/open-rpc/spec/commit/9c31f53)) 241 | * better definitions ([aca0dff](https://github.com/open-rpc/spec/commit/aca0dff)) 242 | * capitalize must ([3a55a0f](https://github.com/open-rpc/spec/commit/3a55a0f)) 243 | * capitlization fix ([36724ca](https://github.com/open-rpc/spec/commit/36724ca)) 244 | * center sponsored by ([52c63e0](https://github.com/open-rpc/spec/commit/52c63e0)) 245 | * change discovery to discover ([149b79c](https://github.com/open-rpc/spec/commit/149b79c)) 246 | * change discovery to discover ([be98ab4](https://github.com/open-rpc/spec/commit/be98ab4)) 247 | * change name of runtime expressions standard ([de484d1](https://github.com/open-rpc/spec/commit/de484d1)) 248 | * change name to pairing from mapping ([3856cc9](https://github.com/open-rpc/spec/commit/3856cc9)) 249 | * components cant be reference objects ([9496962](https://github.com/open-rpc/spec/commit/9496962)) 250 | * content descriptor object required default ([11ccc36](https://github.com/open-rpc/spec/commit/11ccc36)) 251 | * content-descriptor-object link ([7d3c257](https://github.com/open-rpc/spec/commit/7d3c257)) 252 | * contentDescriptor over parametersObject ([eb986c3](https://github.com/open-rpc/spec/commit/eb986c3)) 253 | * define JSON String templating language for template strings ([8437e18](https://github.com/open-rpc/spec/commit/8437e18)) 254 | * descriptions shouldnt read 'a short description' ([66425b1](https://github.com/open-rpc/spec/commit/66425b1)) 255 | * desired values text for runtime expression ([435abb9](https://github.com/open-rpc/spec/commit/435abb9)) 256 | * discovery to reflect JSON RPC spec ([225ea77](https://github.com/open-rpc/spec/commit/225ea77)) 257 | * dont center examplePairingObject ([c24c1cc](https://github.com/open-rpc/spec/commit/c24c1cc)), closes [#110](https://github.com/open-rpc/spec/issues/110) 258 | * dont use method text in content descriptor ([4a3cd0c](https://github.com/open-rpc/spec/commit/4a3cd0c)), closes [#109](https://github.com/open-rpc/spec/issues/109) 259 | * error docs meaning field to data ([336873e](https://github.com/open-rpc/spec/commit/336873e)) 260 | * errors ([c881703](https://github.com/open-rpc/spec/commit/c881703)) 261 | * example params may be a reference object ([704d14a](https://github.com/open-rpc/spec/commit/704d14a)) 262 | * example-object result ([2ad2987](https://github.com/open-rpc/spec/commit/2ad2987)) 263 | * fix ci ([31eded4](https://github.com/open-rpc/spec/commit/31eded4)) 264 | * fix extra whitespace ([d91bf21](https://github.com/open-rpc/spec/commit/d91bf21)) 265 | * fix indentation ([14b6635](https://github.com/open-rpc/spec/commit/14b6635)) 266 | * fix missing quotes around methods ([67dd189](https://github.com/open-rpc/spec/commit/67dd189)) 267 | * fixup remaining errors ([481abfc](https://github.com/open-rpc/spec/commit/481abfc)) 268 | * fixups ([d187d26](https://github.com/open-rpc/spec/commit/d187d26)) 269 | * formatting on server vars ([2194c76](https://github.com/open-rpc/spec/commit/2194c76)) 270 | * incorrect methods example ([37c2753](https://github.com/open-rpc/spec/commit/37c2753)) 271 | * invalid json and typos ([e32ff7c](https://github.com/open-rpc/spec/commit/e32ff7c)) 272 | * json broken ([ace1fc0](https://github.com/open-rpc/spec/commit/ace1fc0)) 273 | * JSON-RPC over JSON RPC ([3b04e68](https://github.com/open-rpc/spec/commit/3b04e68)) 274 | * keep APIs wording use consistent ([e4310f4](https://github.com/open-rpc/spec/commit/e4310f4)) 275 | * left over dasherizing ([01900d4](https://github.com/open-rpc/spec/commit/01900d4)) 276 | * link request param fix ([b93e2f5](https://github.com/open-rpc/spec/commit/b93e2f5)) 277 | * links example + contentDescriptor example + method example ([a7ff97d](https://github.com/open-rpc/spec/commit/a7ff97d)) 278 | * links in method ([24646ee](https://github.com/open-rpc/spec/commit/24646ee)) 279 | * links should be arrays ([081aa23](https://github.com/open-rpc/spec/commit/081aa23)) 280 | * lint fixes ([05f5f87](https://github.com/open-rpc/spec/commit/05f5f87)) 281 | * localhost if server is empty ([4f942b3](https://github.com/open-rpc/spec/commit/4f942b3)) 282 | * lowercase error field names ([948f535](https://github.com/open-rpc/spec/commit/948f535)) 283 | * messed up spacing ([2cdc1f4](https://github.com/open-rpc/spec/commit/2cdc1f4)) 284 | * method over operation ([546275d](https://github.com/open-rpc/spec/commit/546275d)) 285 | * method params ([9e721f8](https://github.com/open-rpc/spec/commit/9e721f8)) 286 | * method servers ([25d4304](https://github.com/open-rpc/spec/commit/25d4304)) 287 | * method-examples link and description ([7f9da28](https://github.com/open-rpc/spec/commit/7f9da28)) 288 | * methodObject tag link ([b3f9bd6](https://github.com/open-rpc/spec/commit/b3f9bd6)) 289 | * methods should be method ([9881f8f](https://github.com/open-rpc/spec/commit/9881f8f)) 290 | * move conventions and resource up in the readme ([95fe209](https://github.com/open-rpc/spec/commit/95fe209)) 291 | * move to pristine ([16470f1](https://github.com/open-rpc/spec/commit/16470f1)) 292 | * nameExample JSON syntax error ([5d0f799](https://github.com/open-rpc/spec/commit/5d0f799)) 293 | * reference json schema for $refs ([c26b217](https://github.com/open-rpc/spec/commit/c26b217)) 294 | * reference to openapi ([157d238](https://github.com/open-rpc/spec/commit/157d238)) 295 | * remove a level of header indent ([0f7a0b4](https://github.com/open-rpc/spec/commit/0f7a0b4)) 296 | * remove comment about organization ([f1a3347](https://github.com/open-rpc/spec/commit/f1a3347)) 297 | * remove datatypes and defer to json schema spec ([2c4a895](https://github.com/open-rpc/spec/commit/2c4a895)) 298 | * remove document structure ([b863f5f](https://github.com/open-rpc/spec/commit/b863f5f)) 299 | * remove examples from spec ([9acf1c1](https://github.com/open-rpc/spec/commit/9acf1c1)), closes [#123](https://github.com/open-rpc/spec/issues/123) 300 | * remove extra stuff ([#7](https://github.com/open-rpc/spec/issues/7)) ([2bcaa35](https://github.com/open-rpc/spec/commit/2bcaa35)) 301 | * remove hard tabs rule ([10efb9a](https://github.com/open-rpc/spec/commit/10efb9a)) 302 | * remove header a tag wrappers ([3bc7ba7](https://github.com/open-rpc/spec/commit/3bc7ba7)) 303 | * remove left over a wrapper ([ffd8f23](https://github.com/open-rpc/spec/commit/ffd8f23)) 304 | * remove linkRequest ([04e9327](https://github.com/open-rpc/spec/commit/04e9327)) 305 | * remove old cname file ([aeb85a3](https://github.com/open-rpc/spec/commit/aeb85a3)) 306 | * remove old license ([54950a2](https://github.com/open-rpc/spec/commit/54950a2)) 307 | * remove references to anything yaml related ([6e90463](https://github.com/open-rpc/spec/commit/6e90463)) 308 | * remove trash files ([0e2c660](https://github.com/open-rpc/spec/commit/0e2c660)) 309 | * remove travis.yml ([#9](https://github.com/open-rpc/spec/issues/9)) ([71be1bf](https://github.com/open-rpc/spec/commit/71be1bf)) 310 | * remove unneeded schema spec duplication ([a542cd9](https://github.com/open-rpc/spec/commit/a542cd9)) 311 | * remove whitespace rule ([9118866](https://github.com/open-rpc/spec/commit/9118866)) 312 | * Rename LICENSE -> LICENSE.md ([6389e32](https://github.com/open-rpc/spec/commit/6389e32)) 313 | * replace github for Github ([161f729](https://github.com/open-rpc/spec/commit/161f729)) 314 | * result over response ([bcbc3a7](https://github.com/open-rpc/spec/commit/bcbc3a7)) 315 | * results and params docs busted ([91076e8](https://github.com/open-rpc/spec/commit/91076e8)) 316 | * results in link example ([4894a77](https://github.com/open-rpc/spec/commit/4894a77)) 317 | * results is now result ([71f3010](https://github.com/open-rpc/spec/commit/71f3010)) 318 | * revert example changes ([a333a7a](https://github.com/open-rpc/spec/commit/a333a7a)) 319 | * rewriting existing JSON-RPC API clarification ([9d7d53d](https://github.com/open-rpc/spec/commit/9d7d53d)) 320 | * runtime expression table ([2f38638](https://github.com/open-rpc/spec/commit/2f38638)) 321 | * schema required on contentDescriptorObject ([46efa4d](https://github.com/open-rpc/spec/commit/46efa4d)), closes [#126](https://github.com/open-rpc/spec/issues/126) 322 | * server needs name ([a1ca601](https://github.com/open-rpc/spec/commit/a1ca601)) 323 | * suggestion required link name ([1e29076](https://github.com/open-rpc/spec/commit/1e29076)) 324 | * table misformated ([928a8c8](https://github.com/open-rpc/spec/commit/928a8c8)) 325 | * tags shouldnt be in root ([58c914b](https://github.com/open-rpc/spec/commit/58c914b)) 326 | * typo in CONTRIBUTING.md and compose command in BUILDING.md ([19f68fa](https://github.com/open-rpc/spec/commit/19f68fa)) 327 | * unescaped by-position ([8f264ae](https://github.com/open-rpc/spec/commit/8f264ae)), closes [#90](https://github.com/open-rpc/spec/issues/90) 328 | * unique error codes ([3205b7d](https://github.com/open-rpc/spec/commit/3205b7d)) 329 | * update BUILDING.md ([02d18c5](https://github.com/open-rpc/spec/commit/02d18c5)) 330 | * update BUILDING.md typo ([e89ef99](https://github.com/open-rpc/spec/commit/e89ef99)) 331 | * update CONTRIBUTING.md adding docs ([944931c](https://github.com/open-rpc/spec/commit/944931c)) 332 | * update CONTRIBUTING.md choppy code changes and testing ([84b8d67](https://github.com/open-rpc/spec/commit/84b8d67)) 333 | * update CONTRIBUTING.md grammer around preview markdown ([cbce371](https://github.com/open-rpc/spec/commit/cbce371)) 334 | * update CONTRIBUTING.md how to fork a repo ([b2df0bb](https://github.com/open-rpc/spec/commit/b2df0bb)) 335 | * update CONTRIBUTING.md to get rid of cloning or forking ([cd0aeeb](https://github.com/open-rpc/spec/commit/cd0aeeb)) 336 | * update CONTRIBUTING.md typo ([339fee5](https://github.com/open-rpc/spec/commit/339fee5)) 337 | * update link to template language ([f8dafd1](https://github.com/open-rpc/spec/commit/f8dafd1)) 338 | * update README introduction list formatting ([adedd85](https://github.com/open-rpc/spec/commit/adedd85)) 339 | * update README.md remove YAML ([69a4dd0](https://github.com/open-rpc/spec/commit/69a4dd0)) 340 | * update README.md simplify open source grammar ([fe4111f](https://github.com/open-rpc/spec/commit/fe4111f)) 341 | * update README.md typo its ([832ca2c](https://github.com/open-rpc/spec/commit/832ca2c)) 342 | * updated README ([11d4da2](https://github.com/open-rpc/spec/commit/11d4da2)) 343 | * updated README ([#2](https://github.com/open-rpc/spec/issues/2)) ([16f8f29](https://github.com/open-rpc/spec/commit/16f8f29)) 344 | * use Github Flavored Markdown ([f3303cf](https://github.com/open-rpc/spec/commit/f3303cf)) 345 | * use OpenRPC over OPENRPC ([3ffabba](https://github.com/open-rpc/spec/commit/3ffabba)), closes [#20](https://github.com/open-rpc/spec/issues/20) 346 | * use raw link for etc labs logo ([5f52284](https://github.com/open-rpc/spec/commit/5f52284)) 347 | * **build:** add script ([ed511e1](https://github.com/open-rpc/spec/commit/ed511e1)) 348 | * **components:** add examplePairingObjects ([f7e735d](https://github.com/open-rpc/spec/commit/f7e735d)), closes [#98](https://github.com/open-rpc/spec/issues/98) 349 | * **components:** add tagObject ([d449c8a](https://github.com/open-rpc/spec/commit/d449c8a)), closes [#99](https://github.com/open-rpc/spec/issues/99) 350 | * **contentDescriptor:** name is required ([41927d8](https://github.com/open-rpc/spec/commit/41927d8)), closes [#88](https://github.com/open-rpc/spec/issues/88) 351 | * use runtime expression for server.url ([967f1b3](https://github.com/open-rpc/spec/commit/967f1b3)) 352 | * **examplePairing:** fix table formatting ([82bc779](https://github.com/open-rpc/spec/commit/82bc779)) 353 | * use runtime expression as type for server url ([d932d0e](https://github.com/open-rpc/spec/commit/d932d0e)) 354 | * wip ([ea774c7](https://github.com/open-rpc/spec/commit/ea774c7)) 355 | * **versions:** formatting issues resolved ([bc26551](https://github.com/open-rpc/spec/commit/bc26551)) 356 | * wrong brackets ([32f5fb9](https://github.com/open-rpc/spec/commit/32f5fb9)) 357 | * **examples:** add a link to the examples ([2f378b9](https://github.com/open-rpc/spec/commit/2f378b9)) 358 | * **format:** more specific about patterned field uniqueness ([3654295](https://github.com/open-rpc/spec/commit/3654295)) 359 | * **methodObject:** change parameters to params ([89f4692](https://github.com/open-rpc/spec/commit/89f4692)), closes [#117](https://github.com/open-rpc/spec/issues/117) 360 | * **methodObject:** method name is required ([84c8ded](https://github.com/open-rpc/spec/commit/84c8ded)), closes [#118](https://github.com/open-rpc/spec/issues/118) 361 | * **methodObject:** params are required ([99995a5](https://github.com/open-rpc/spec/commit/99995a5)), closes [#108](https://github.com/open-rpc/spec/issues/108) 362 | * **server-description:** typo with github md link ([9a4e957](https://github.com/open-rpc/spec/commit/9a4e957)) 363 | * **serverObject:** add summary ([544b174](https://github.com/open-rpc/spec/commit/544b174)), closes [#108](https://github.com/open-rpc/spec/issues/108) 364 | * **tagObject:** add summary ([d868c3f](https://github.com/open-rpc/spec/commit/d868c3f)) 365 | * **versions:** consistent use of x ([3df1d5c](https://github.com/open-rpc/spec/commit/3df1d5c)) 366 | * **versions:** remove extra words ([a2558ba](https://github.com/open-rpc/spec/commit/a2558ba)) 367 | 368 | 369 | ### Features 370 | 371 | * add description and pairing to examples ([c76b852](https://github.com/open-rpc/spec/commit/c76b852)) 372 | * add empty circle ci config ([cf7f746](https://github.com/open-rpc/spec/commit/cf7f746)) 373 | * add examples mapping object ([3b4294a](https://github.com/open-rpc/spec/commit/3b4294a)) 374 | * add mdv checking to circleci ([7f217ff](https://github.com/open-rpc/spec/commit/7f217ff)) 375 | * add more resources to README ([0a0e5b4](https://github.com/open-rpc/spec/commit/0a0e5b4)) 376 | * add oneOf to the spec ([966cea0](https://github.com/open-rpc/spec/commit/966cea0)) 377 | * add probot ([66f591b](https://github.com/open-rpc/spec/commit/66f591b)) 378 | * add resources for documentation driven development ([89be66a](https://github.com/open-rpc/spec/commit/89be66a)) 379 | * add service description to the spec ([cd32941](https://github.com/open-rpc/spec/commit/cd32941)) 380 | * gh pages from master ([ff0d20f](https://github.com/open-rpc/spec/commit/ff0d20f)), closes [#124](https://github.com/open-rpc/spec/issues/124) 381 | * initial commit ([508cf20](https://github.com/open-rpc/spec/commit/508cf20)) 382 | * pristine all the things ([fdf7380](https://github.com/open-rpc/spec/commit/fdf7380)) 383 | * ref oneOf throughout the spec ([824cd61](https://github.com/open-rpc/spec/commit/824cd61)) 384 | * semantic release and build ([275c10a](https://github.com/open-rpc/spec/commit/275c10a)) 385 | * use params over parameters ([ffae341](https://github.com/open-rpc/spec/commit/ffae341)), closes [#33](https://github.com/open-rpc/spec/issues/33) 386 | -------------------------------------------------------------------------------- /spec.md: -------------------------------------------------------------------------------- 1 | # OpenRPC Specification 2 | 3 | 4 | 5 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://tools.ietf.org/html/bcp14) [RFC2119](https://tools.ietf.org/html/rfc2119) [RFC8174](https://tools.ietf.org/html/rfc8174) when, and only when, they appear in all capitals, as shown here. 6 | 7 | In the following description, if a field is not explicitly **REQUIRED** or described with a MUST or SHALL, it can be considered OPTIONAL. 8 | 9 | This document is licensed under [The Apache License, Version 2.0](https://www.apache.org/licenses/LICENSE-2.0.html). 10 | 11 | 12 | 13 | 14 | # Introduction 15 | 16 | The OpenRPC Specification defines a standard, programming language-agnostic interface description for [JSON-RPC 2.0 APIs](https://www.jsonrpc.org/specification), which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic. When properly defined via OpenRPC, a consumer can understand and interact with the remote service with a minimal amount of implementation logic. Similar to what interface descriptions have done for lower-level programming, the OpenRPC Specification removes guesswork in calling a service. 17 | 18 | Use cases for machine-readable JSON-RPC API definition documents include, but are not limited to: 19 | 20 | - interactive documentation 21 | - code generation for documentation 22 | - clients 23 | - servers 24 | - automation of test cases. 25 | 26 | OpenRPC documents describe a JSON-RPC APIs services and are represented in JSON format. These documents may either be produced and served statically or be generated dynamically from an application. 27 | 28 | The OpenRPC Specification does not require rewriting existing JSON-RPC APIs. It does not require binding any software to a service — the service being described may not even be owned by the creator of its description. It does, however, require the capabilities of the service be described in the structure of the OpenRPC Specification. Not all services can be described by OpenRPC — this specification is not intended to cover REST APIs - It is exclusively for APIs which adhere to the JSON-RPC 2.0 spec. The OpenRPC Specification does not mandate a specific development process such as design-first or code-first. It does facilitate either technique by establishing clear interactions with a JSON-RPC API. 29 | 30 | # Definitions 31 | 32 | ## OpenRPC Document 33 | 34 | A document (or set of documents) that defines or describes an API. An OpenRPC document uses and conforms to the OpenRPC Specification. 35 | 36 | ## Patterned Field 37 | 38 | A field (key value pair) where the key name is supplied by the user, and the value is defined by the specification for the patterned field. The Field Pattern is a Regular expression. 39 | 40 | ## Regular Expression 41 | 42 | Regular expressions within the OpenRPC specification and tooling is RECOMMENDED to be a [Perl Compatible Regular Expressions](https://www.pcre.org/). That being said, tooling implementers SHOULD adhere to [ECMA-262 6th Edition Regular Expressions](https://www.ecma-international.org/ecma-262/6.0/#sec-regexp-regular-expression-objects). 43 | 44 | ## Official OpenRPC Tooling 45 | 46 | Tooling that is built, maintained and documented by the OpenRPC organization. It is meant to be used as a functional reference implementation of the Specification. Users of the OpenRPC Specification are encouraged to create versions of the tooling as their own organization/projects. 47 | 48 | # Versions 49 | 50 | The OpenRPC Specification is versioned using [Semantic Versioning 2.0.0](https://semver.org/spec/v2.0.0.html). 51 | 52 | The `major.minor` portion of the semver (for example `1.0.x`) SHALL designate the OpenRPC feature set. Typically, `.patch` versions address errors in this document, not the feature set. Tooling which supports OpenRPC 1.0.0 SHOULD be compatible with all OpenRPC `1.0.x` versions. The patch version SHOULD NOT be considered by tooling, making no distinction between `1.0.0` and `1.0.1` for example. 53 | 54 | Subsequent minor version releases of the OpenRPC Specification (incrementing the `minor` version number) SHOULD NOT interfere with tooling developed to a lower minor version and same major version. Thus a hypothetical `1.1.0` specification SHOULD be usable with tooling designed for `1.0.0`. 55 | 56 | An OpenRPC document compatible with OpenRPC 1.0.0 contains a required [`openrpc`](#openrpc-version) field which designates the semantic version of the OpenRPC that it uses. 57 | 58 | # Format 59 | 60 | An OpenRPC document that conforms to the OpenRPC Specification is itself a JSON object, which must be represented in JSON format. Due to the nature of JSON-RPC APIs using JSON formats, strictly use JSON only [as described here](https://tools.ietf.org/html/rfc7159). If you wish to use any other format than JSON, it should be converted outside of any OpenRPC tooling. 61 | 62 | It is RECOMMENDED that the OpenRPC document be named: `openrpc.json`. Tooling that requires an OpenRPC document as input MAY assume the default document location to be `./openrpc.json`, where the `./` represents the current working directory. 63 | 64 | All field names in the specification are **case sensitive**. [CamelCase](https://trac.tools.ietf.org/group/tools/trac/wiki/CamelCase) SHOULD be used for all key names. 65 | This includes all fields that are used as keys in a map, except where explicitly noted that keys are **case insensitive**. 66 | 67 | [According to the JSON specification for objects](https://tools.ietf.org/html/rfc7159#section-4), key names SHOULD be unique. However, To avoid ambiguity, all [patterned fields](#patterned-field) in an OpenRPC document MUST have unique key names within the containing object. 68 | 69 | # Rich Text Formatting 70 | 71 | Throughout the specification `description` fields are noted as supporting Github markdown formatting. 72 | Where OpenRPC tooling renders rich text it MUST support, at a minimum, markdown syntax as described by [GitHub Flavored Markdown](https://github.github.com/gfm/). Tooling MAY choose to ignore some GitHub Flavored Markdown features to address security concerns. 73 | 74 | # Service Discovery Method 75 | 76 | JSON-RPC APIs can support the OpenRPC specification by implementing a service discovery method that will return the OpenRPC schema for the JSON-RPC API. The method MUST be named `rpc.discover`. The `rpc.` prefix is a reserved method prefix for JSON-RPC 2.0 specification system extensions. Below is the OpenRPC specification for the service discovery method: 77 | 78 | ```json 79 | { 80 | "methods": [ 81 | { 82 | "name": "rpc.discover", 83 | "description": "Returns an OpenRPC schema as a description of this service", 84 | "params": [], 85 | "result": { 86 | "name": "OpenRPC Schema", 87 | "schema": { 88 | "$ref": "https://raw.githubusercontent.com/open-rpc/meta-schema/master/schema.json" 89 | } 90 | } 91 | } 92 | ] 93 | } 94 | ``` 95 | 96 | # Examples 97 | 98 | Example OpenRPC documents can be found in the [OpenRPC Examples Repository](https://github.com/open-rpc/examples). There SHOULD be an example that uses every concept of the spec. These examples are to be used as the basis of testing for all the Official OpenRPC tooling. 99 | 100 | # Meta JSON Schema 101 | 102 | Validating an OpenRPC document can be accomplished using the OpenRPC MetaSchema. The OpenRPC MetaSchema is based on the [Draft 07 JSON Schema](https://json-schema.org/draft-07/schema), and may be used as a JSON meta-schema for various tooling use. Each field in the Specification MUST be included in the OpenRPC MetaSchema, including all constraints that are possible to model with [Draft 07 JSON Schema](https://json-schema.org/draft-07/schema). 103 | 104 | # OpenRPC Object 105 | 106 | This is the root object of the [OpenRPC document](#openrpc-document). The contents of this object represent a whole [OpenRPC document](#openrpc-document). How this object is constructed or stored is outside the scope of the OpenRPC Specification. 107 | 108 | Field Name | Type | Description 109 | ---|:---:|--- 110 | openrpc | `string` | **REQUIRED**. This string MUST be the [semantic version number](https://semver.org/spec/v2.0.0.html) of the [OpenRPC Specification version](#versions) that the OpenRPC document uses. The `openrpc` field SHOULD be used by tooling specifications and clients to interpret the OpenRPC document. This is *not* related to the API [`info.version`](#info-version) string. 111 | info | [Info Object](#info-object) | **REQUIRED**. Provides metadata about the API. The metadata MAY be used by tooling as required. 112 | servers | [[Server Object](#server-object)] | An array of Server Objects, which provide connectivity information to a target server. If the `servers` property is not provided, or is an empty array, the default value would be a [Server Object](#server-object) with a [url](#server-url) value of `localhost`. 113 | methods | [[Method Object](#method-object) \| [Reference Object](#reference-object)] | **REQUIRED**. The available methods for the API. While it is required, the array may be empty (to handle security filtering, for example). 114 | components | [Components Object](#components-object) | An element to hold various schemas for the specification. 115 | externalDocs | [External Documentation Object](#external-documentation-object) | Additional external documentation. 116 | 117 | This object MAY be extended with [Specification Extensions](#specification-extensions). 118 | 119 | ## Info Object 120 | 121 | The object provides metadata about the API. 122 | The metadata MAY be used by the clients if needed, and MAY be presented in editing or documentation generation tools for convenience. 123 | 124 | Field Name | Type | Description 125 | ---|:---:|--- 126 | title | `string` | **REQUIRED**. The title of the application. 127 | description | `string` | A verbose description of the application. [GitHub Flavored Markdown syntax](https://github.github.com/gfm/) MAY be used for rich text representation. 128 | termsOfService | `string` | A URL to the Terms of Service for the API. MUST be in the format of a URL. 129 | contact | [Contact Object](#contact-object) | The contact information for the exposed API. 130 | license | [License Object](#license-object) | The license information for the exposed API. 131 | version | `string` | **REQUIRED**. The version of the OpenRPC document (which is distinct from the [OpenRPC Specification version](#openrpc-version) or the API implementation version). 132 | 133 | This object MAY be extended with [Specification Extensions](#specification-extensions). 134 | 135 | ### Contact Object 136 | 137 | Contact information for the exposed API. 138 | 139 | Field Name | Type | Description 140 | ---|:---:|--- 141 | name | `string` | The identifying name of the contact person/organization. 142 | url | `string` | The URL pointing to the contact information. MUST be in the format of a URL. 143 | email | `string` | The email address of the contact person/organization. MUST be in the format of an email address. 144 | 145 | This object MAY be extended with [Specification Extensions](#specification-extensions). 146 | 147 | ### License Object 148 | 149 | License information for the exposed API. 150 | 151 | Field Name | Type | Description 152 | ---|:---:|--- 153 | name | `string` | **REQUIRED**. The license name used for the API. 154 | url | `string` | A URL to the license used for the API. MUST be in the format of a URL. 155 | 156 | This object MAY be extended with [Specification Extensions](#specification-extensions). 157 | 158 | ## Server Object 159 | 160 | An object representing a Server. 161 | 162 | Field Name | Type | Description 163 | ---|:---:|--- 164 | name | `string` | **REQUIRED**. A name to be used as the cannonical name for the server. 165 | url | [Runtime Expression](#runtime-expression) | **REQUIRED**. A URL to the target host. This URL supports Server Variables and MAY be relative, to indicate that the host location is relative to the location where the OpenRPC document is being served. [Server Variables](#server-variables) are passed into the [Runtime Expression](#runtime-expression) to produce a server URL. 166 | summary | `string` | A short summary of what the server is. 167 | description | `string` | An optional string describing the host designated by the URL. [GitHub Flavored Markdown syntax](https://github.github.com/gfm/) MAY be used for rich text representation. 168 | variables | Map[`string`, [Server Variable Object](#server-variable-object)] | A map between a variable name and its value. The value is passed into the [Runtime Expression](#runtime-expression) to produce a server URL. 169 | 170 | This object MAY be extended with [Specification Extensions](#specification-extensions). 171 | 172 | ### Server Variable Object 173 | 174 | An object representing a Server Variable for server URL template substitution. 175 | 176 | Field Name | Type | Description 177 | ---|:---:|--- 178 | enum | `[string]` | An enumeration of string values to be used if the substitution options are from a limited set. 179 | default | `string` | **REQUIRED**. The default value to use for substitution, which SHALL be sent if an alternate value is *not* supplied. Note this behavior is different than the [Schema Object's](#schema-object) treatment of default values, because in those cases parameter values are optional. 180 | description | `string` | An optional description for the server variable. [GitHub Flavored Markdown syntax](https://github.github.com/gfm/) MAY be used for rich text representation. 181 | 182 | This object MAY be extended with [Specification Extensions](#specification-extensions). 183 | 184 | ## Method Object 185 | 186 | Describes the interface for the given method name. The method name is used as the `method` field of the JSON-RPC body. It therefore MUST be unique. 187 | 188 | Field Name | Type | Description 189 | ---|:---:|--- 190 | name | `string` | **REQUIRED**. The cannonical name for the method. The name MUST be unique within the methods array. 191 | tags | [[Tag Object](#tag-object) \| [Reference Object](#reference-object)] | A list of tags for API documentation control. Tags can be used for logical grouping of methods by resources or any other qualifier. 192 | summary | `string` | A short summary of what the method does. 193 | description | `string` | A verbose explanation of the method behavior. [GitHub Flavored Markdown syntax](https://github.github.com/gfm/) MAY be used for rich text representation. 194 | externalDocs | [External Documentation Object](#external-documentation-object) | Additional external documentation for this method. 195 | params | [[Content Descriptor](#content-descriptor-object) \| [Reference Object](#reference-object)] | **REQUIRED**. A list of parameters that are applicable for this method. The list MUST NOT include duplicated parameters and therefore require [name](#content-descriptor-name) to be unique. The list can use the [Reference Object](#reference-object) to link to parameters that are defined by the [Content Descriptor Object](#content-descriptor-object). All optional params (content descriptor objects with "required": false) MUST be positioned after all required params in the list. 196 | result | [Content Descriptor](#content-descriptor-object) \| [Reference Object](#reference-object) | The description of the result returned by the method. If defined, it MUST be a Content Descriptor or Reference Object. If undefined, the method MUST only be used as a [notification](https://www.jsonrpc.org/specification#notification). 197 | deprecated | `boolean` | Declares this method to be deprecated. Consumers SHOULD refrain from usage of the declared method. Default value is `false`. 198 | servers | [[Server Object](#server-object)] | An alternative `servers` array to service this method. If an alternative `servers` array is specified at the Root level, it will be overridden by this value. 199 | errors | [[Error Object](#error-object) \| [Reference Object](#reference-object)] | A list of custom application defined errors that MAY be returned. The Errors MUST have unique error codes. 200 | links | [[Link Object](#link-object) \| [Reference Object](#reference-object)] | A list of possible links from this method call. 201 | paramStructure | `"by-name"` \| `"by-position"` \| `"either"` | The expected format of the parameters. [As per the JSON-RPC 2.0 specification](https://www.jsonrpc.org/specification#parameter_structures), the params of a [JSON-RPC request object](https://www.jsonrpc.org/specification#request_object) may be an array, object, or either (represented as `by-position`, `by-name`, and `either` respectively). When a method has a `paramStructure` value of `by-name`, callers of the method MUST send a [JSON-RPC request object](https://www.jsonrpc.org/specification#request_object) whose `params` field is an object. Further, the key names of the `params` object MUST be the same as the [`contentDescriptor.name`](#content-descriptor-name)s for the given method. Defaults to `"either"`. 202 | examples | [[Example Pairing Object](#example-pairing-object) \| [Reference Object](#reference-object)] | Array of [Example Pairing Objects](#example-pairing-object) where each example includes a valid params-to-result [Content Descriptor](#content-descriptor-object) pairing. 203 | 204 | This object MAY be extended with [Specification Extensions](#specification-extensions). 205 | 206 | ### Content Descriptor Object 207 | 208 | Content Descriptors are objects that do just as they suggest - describe content. They are reusable ways of describing either parameters or result. They MUST have a schema. 209 | 210 | Field Name | Type | Description 211 | ---|:---:|--- 212 | name | `string` | **REQUIRED**. Name of the content that is being described. If the content described is a method parameter assignable [`by-name`](#method-param-structure), this field SHALL define the parameter's key (*ie* name). 213 | summary | `string` | A short summary of the content that is being described. 214 | description | `string` | A verbose explanation of the content descriptor behavior. [GitHub Flavored Markdown syntax](https://github.github.com/gfm/) MAY be used for rich text representation. 215 | required | `boolean` | Determines if the content is a required field. Default value is `false`. 216 | schema | [Schema Object](#schema-object) | **REQUIRED**. Schema that describes the content. 217 | deprecated | `boolean` | Specifies that the content is deprecated and SHOULD be transitioned out of usage. Default value is `false`. 218 | 219 | This object MAY be extended with [Specification Extensions](#specification-extensions). 220 | 221 | #### Schema Object 222 | 223 | The Schema Object allows the definition of input and output data types. 224 | The Schema Objects MUST follow the specifications outline in the [JSON Schema Specification 7](https://json-schema.org/draft-07/json-schema-release-notes.html) 225 | Alternatively, any time a Schema Object can be used, a [Reference Object](#reference-object) can be used in its place. This allows referencing definitions instead of defining them inline. 226 | 227 | This object MAY be extended with [Specification Extensions](#specification-extensions). 228 | 229 | ### Example Pairing Object 230 | 231 | The Example Pairing object consists of a set of example params and result. The result is what you can expect from the JSON-RPC service given the exact params. 232 | 233 | Field Name | Type | Description 234 | ---|:---:|--- 235 | name | `string` | **REQUIRED** Name for the example pairing. 236 | description | `string` | A verbose explanation of the example pairing. 237 | summary | `string` | Short description for the example pairing. 238 | params | [[Example Object](#example-object) \| [Reference Object](#reference-object)] | **REQUIRED** Example parameters. 239 | result | [Example Object](#example-object) \| [Reference Object](#reference-object) | Example result. When not provided, the example pairing represents usage of the method as a notification. 240 | error | [Example Object](#example-object) \| [Reference Object](#reference-object) | Represents an example error response. The provided [Example Object](#example-object) MUST have the entire error object as its value. If provided, the [`examplePairing.result`](#example-pairing-result) must not be provided. 241 | 242 | This object MAY be extended with [Specification Extensions](#specification-extensions). 243 | 244 | #### Example Object 245 | 246 | The Example object is an object that defines an example that is intended to match the `schema` of a given [Content Descriptor](#content-descriptor-schema). 247 | 248 | Field Name | Type | Description 249 | ---|:---:|--- 250 | name | `string` | Cannonical name of the example. 251 | summary | `string` | Short description for the example. 252 | description | `string` | A verbose explanation of the example. [GitHub Flavored Markdown syntax](https://github.github.com/gfm/) MAY be used for rich text representation. 253 | value | Any | Embedded literal example. The `value` field and `externalValue` field are mutually exclusive. To represent examples of media types that cannot naturally represented in JSON, use a string value to contain the example, escaping where necessary. 254 | externalValue | `string` | A URL that points to the literal example. This provides the capability to reference examples that cannot easily be included in JSON documents. The `value` field and `externalValue` field are mutually exclusive. 255 | 256 | This object MAY be extended with [Specification Extensions](#specification-extensions). 257 | 258 | In all cases, the example value is expected to be compatible with the type schema of its associated value. Tooling implementations MAY choose to validate compatibility automatically, and reject the example value(s) if incompatible. 259 | 260 | ### Link Object 261 | 262 | The `Link object` represents a possible design-time link for a result. 263 | The presence of a link does not guarantee the caller's ability to successfully invoke it, rather it provides a known relationship and traversal mechanism between results and other methods. 264 | 265 | Unlike *dynamic* links (i.e. links provided **in** the result payload), the OpenRPC linking mechanism does not require link information in the runtime result. 266 | 267 | For computing links, and providing instructions to execute them, a [runtime expression](#runtime-expression) is used for accessing values in an method and using them as parameters while invoking the linked method. 268 | 269 | Field Name | Type | Description 270 | ---|:---:|--- 271 | name | `string` | **REQUIRED**. Cannonical name of the link. 272 | description | `string` | A description of the link. [GitHub Flavored Markdown syntax](https://github.github.com/gfm/) MAY be used for rich text representation. 273 | summary | `string` | Short description for the link. 274 | method | `string` | The name of an *existing*, resolvable OpenRPC method, as defined with a unique `method`. This field MUST resolve to a unique [Method Object](#method-object). As opposed to Open Api, Relative `method` values ARE NOT permitted. 275 | params | Map[`string`, `Any` \| [Runtime Expression](#runtime-expression)] | A map representing parameters to pass to a method as specified with `method`. The key is the parameter name to be used, whereas the value can be a constant or a [runtime expression](#runtime-expression) to be evaluated and passed to the linked method. 276 | server | [Server Object](#server-object) | A server object to be used by the target method. 277 | 278 | A linked method must be identified directly, and must exist in the list of methods defined by the [Methods Object](#method-object). 279 | 280 | When a runtime expression fails to evaluate, no parameter value is passed to the target method. 281 | 282 | Values from the result can be used to drive a linked method. 283 | 284 | Clients follow all links at their discretion. 285 | Neither permissions, nor the capability to make a successful call to that link, is guaranteed 286 | solely by the existence of a relationship. 287 | 288 | This object MAY be extended with [Specification Extensions](#specification-extensions). 289 | 290 | #### Runtime Expression 291 | 292 | Runtime expressions allow the user to define an expression which will evaluate to a string once the desired value(s) are known. They are used when the desired value of a link or server can only be constructed at run time. 293 | This mechanism is used by [Link Objects](#link-object) and [Server Variables](#server-variables). 294 | 295 | The runtime expression makes use of [JSON Template Language](https://tools.ietf.org/html/draft-jonas-json-template-language-01) syntax. 296 | 297 | The table below provides examples of runtime expressions and examples of their use in a value: 298 | 299 | Runtime expressions preserve the type of the referenced value. 300 | 301 | ### Error Object 302 | 303 | Defines an application level error. 304 | 305 | Field Name | Type | Description 306 | ---|:---:|--- 307 | code | [Application Defined Error Code](https://www.jsonrpc.org/specification#response_object) | **REQUIRED**. A Number that indicates the error type that occurred. This MUST be an integer. The error codes from and including -32768 to -32000 are reserved for pre-defined errors. These pre-defined errors SHOULD be assumed to be returned from any JSON-RPC api. 308 | message | `string` | **REQUIRED**. A String providing a short description of the error. The message SHOULD be limited to a concise single sentence. 309 | data | `any` | A Primitive or Structured value that contains additional information about the error. This may be omitted. The value of this member is defined by the Server (e.g. detailed error information, nested errors etc.). 310 | 311 | ## Components Object 312 | 313 | Holds a set of reusable objects for different aspects of the OpenRPC. 314 | All objects defined within the components object will have no effect on the API unless they are explicitly referenced from properties outside the components object. 315 | 316 | Field Name | Type | Description 317 | ---|:---|--- 318 | contentDescriptors | Map[`string`, [Content Descriptor Object](#content-descriptor-object)] | An object to hold reusable [Content Descriptor Objects](#content-descriptor-object). 319 | schemas | Map[`string`, [Schema Object](#schema-object)] | An object to hold reusable [Schema Objects](#schema-object). 320 | examples | Map[`string`, [Example Object](#example-object)] | An object to hold reusable [Example Objects](#example-object). 321 | links | Map[`string`, [Link Object](#link-object)] | An object to hold reusable [Link Objects](#link-object). 322 | errors | Map[`string`, [Error Object](#error-object)] | An object to hold reusable [Error Objects](#error-object). 323 | examplePairingObjects | Map[`string`, [Example Pairing Object](#example-pairing-object)] | An object to hold reusable [Example Pairing Objects](#example-pairing-object). 324 | tags | Map[`string`, [Tag Object](#tag-object)] | An object to hold reusable [Tag Objects](#tag-object). 325 | 326 | This object MAY be extended with [Specification Extensions](#specification-extensions). 327 | 328 | All the fixed fields declared above are objects that MUST use keys that match the regular expression: `^[a-zA-Z0-9\.\-_]+$` 329 | 330 | ## Tag Object 331 | 332 | Adds metadata to a single tag that is used by the [Method Object](#method-object). 333 | It is not mandatory to have a Tag Object per tag defined in the Method Object instances. 334 | 335 | Field Name | Type | Description 336 | ---|:---:|--- 337 | name | `string` | **REQUIRED**. The name of the tag. 338 | summary | `string` | A short summary of the tag. 339 | description | `string` | A verbose explanation for the tag. [GitHub Flavored Markdown syntax](https://github.github.com/gfm/) MAY be used for rich text representation. 340 | externalDocs | [External Documentation Object](#external-documentation-object) | Additional external documentation for this tag. 341 | 342 | This object MAY be extended with [Specification Extensions](#specification-extensions). 343 | 344 | ## External Documentation Object 345 | 346 | Allows referencing an external resource for extended documentation. 347 | 348 | Field Name | Type | Description 349 | ---|:---:|--- 350 | description | `string` | A verbose explanation of the target documentation. [GitHub Flavored Markdown syntax](https://github.github.com/gfm/) MAY be used for rich text representation. 351 | url | `string` | **REQUIRED**. The URL for the target documentation. Value MUST be in the format of a URL. 352 | 353 | This object MAY be extended with [Specification Extensions](#specification-extensions). 354 | 355 | ## Reference Object 356 | 357 | A simple object to allow referencing other components in the specification, internally and externally. 358 | 359 | The Reference Object is defined by [JSON Schema](https://json-schema.org/draft-07/json-schema-core.html#rfc.section.8.3) and follows the same structure, behavior and rules. 360 | 361 | Field Name | Type | Description 362 | ---|:---:|--- 363 | $ref | `string` | **REQUIRED**. The reference string. 364 | 365 | This object cannot be extended with additional properties and any properties added SHALL be ignored. 366 | 367 | ## Specification Extensions 368 | 369 | While the OpenRPC Specification tries to accommodate most use cases, additional data can be added to extend the specification at certain points. 370 | 371 | The extensions properties are implemented as patterned fields that are always prefixed by `"x-"`. 372 | 373 | Field Pattern | Type | Description 374 | ---|:---:|--- 375 | ^x- | Any | Allows extensions to the OpenRPC Schema. The field name MUST begin with `x-`, for example, `x-internal-id`. The value can be `null`, a primitive, an array or an object. Can have any valid JSON format value. 376 | 377 | The extensions may or may not be supported by the available tooling, but those may be extended as well to add requested support (if tools are internal or open-sourced). 378 | --------------------------------------------------------------------------------