Protocol Buffers Version 3 Language Specification
This is a language specification reference for version 3 of the Protocol Buffers language (proto3). The syntax is specified using Extended Backus-Naur Form (EBNF):
| alternation
() grouping
[] option (zero or one time)
{} repetition (any number of times)
For more information about using proto3, see the language guide.
Lexical elements
Letters and digits
letter = "A" … "Z" | "a" … "z"
decimalDigit = "0" … "9"
octalDigit = "0" … "7"
hexDigit = "0" … "9" | "A" … "F" | "a" … "f"
Protocol Buffers Version 2 Language Specification
This is a language specification reference for version 2 of the Protocol Buffers language (proto2). The syntax is specified using Extended Backus-Naur Form (EBNF):
| alternation
() grouping
[] option (zero or one time)
{} repetition (any number of times)
For more information about using proto2, see the language guide.
Lexical elements
Letters and digits
letter = "A" … "Z" | "a" … "z"
capitalLetter = "A" … "Z"
decimalDigit = "0" … "9"
octalDigit = "0" … "7"
hexDigit = "0" … "9" | "A" … "F" | "a" … "f"
Cap'n Proto Schema Language
Schema Language
Like Protocol Buffers and Thrift (but unlike JSON or MessagePack), Cap’n Proto messages are strongly-typed and not self-describing. You must define your message structure in a special language, then invoke the Cap’n Proto compiler (capnp compile) to generate source code to manipulate that message type in your desired language.
For example:
@0xdbb9ad1f14bf0b36; # unique file ID, generated by `capnp id`
struct Person {
name @0 :Text;
birthdate @3 :Date;
email @1 :Text;
phones @2 :List(PhoneNumber);
struct PhoneNumber {
number @0 :Text;
type @1 :Type;
enum Type {
mobile @0;
home @1;
work @2;
}
}
}
struct Date {
year @0 :Int16;
month @1 :UInt8;
day @2 :UInt8;
}
Tus Resumable Upload Protocol
Version: 1.0.0 (SemVer) Date: 2016-03-25 Authors: Felix Geisendörfer, Kevin van Zonneveld, Tim Koschützki, Naren Venkataraman, Marius Kleidl Collaborators: Bruno de Carvalho, James Butler, Øystein Steimler, Sam Rijs, Khang Toh, Jacques Boscq, Jérémy FRERE, Pieter Hintjens, Stephan Seidt, Aran Wilkinson, Svein Ove Aas, Oliver Anan, Tim, j4james, Julian Reschke, Evert Pot, Jochen Kupperschmidt, Andrew Fenn, Kevin Swiber, Jan Kohlhof, eno, Luke Arduini, Jim Schmid, Jeffrey ‘jf’ Lim, Daniel Lopretto, Mark Murphy, Peter Darrow, Gargaj, Tomasz Rydzyński, Tino de Bruijn, Jonas mg, Christian Ulbrich, Jon Gjengset, Michael Elovskikh, Rick Olson, J. Ryan Stinnett, Ifedapo Olarewaju Robert Nagy
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.
Status
Following SemVer, as of 1.0.0 tus is ready for general adoption. We don’t expect to make breaking changes, but if we do, those will have to be in a 2.0.0. Introducing a new extension or any backwards-compatible change adding new functionality will result in a bumped MINOR version.
Contributing
This protocol is authored and owned by the tus community. We welcome patches and feedback via GitHub. All authors and collaborators will be listed as such in the protocol header.
Please also let us know about any implementations (open source or commercial) if you’d like to be listed on the implementations page.
Abstract
The protocol provides a mechanism for resumable file uploads via HTTP/1.1 (RFC 7230) and HTTP/2 (RFC 7540).
熊猫人
Toyota GT86
OpenAPI Specification
Version 3.0.2
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 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.
This document is licensed under The Apache License, Version 2.0.
Introduction
The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to RESTful APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection. When properly defined, a consumer can understand and interact with the remote service with a minimal amount of implementation logic.
An OpenAPI definition can then be used by documentation generation tools to display the API, code generation tools to generate servers and clients in various programming languages, testing tools, and many other use cases.
YAML 简明参考
§语法说明
在yaml.org（英文）可以找到轻巧而好用的小抄（亦是用YAML表示）及格式说明。下面的内容，是关于基本组件的摘要。
- YAML使用可打印的Unicode字符，可使用UTF-8或UTF-16。
- 使用空白字符为文件缩进来表示结构；不过不能使用跳格字符(TAB)。
- 注解由井字号（ # ）开始，可以出现在一行中的任何位置，而且范围只有一行（也就是一般所谓的单行注解）
- 每个清单成员以单行表示，并用短杠+空白（ - ）起始。或使用方括号（ [ ] ），并用逗号+空白（ , ）分开成员。
- 每个散列表的成员用冒号+空白（ : ）分开键值和内容。或使用大括号（ { } ），并用逗号+空白（ , ）分开。
- 散列表的键值可以用问号 ( ? )起始，用来明确的表示多个词汇组成的键值。
- 字符串平常并不使用引号，但必要的时候可以用双引号 ( " )或单引号 ( ’ )框住。
- 使用双引号表示字符串时，可用倒斜线（ \ ）开始的转义字符（这跟C语言类似）表示特殊字符。
- 区块的字符串用缩进和修饰符（非必要）来和其他数据分隔，有新行保留（preserve）（使用符号 | ）或新行折叠（flod）（使用符号 > ）两种方式。
- 在单一文件中，可用连续三个连字号（—）区分多个文件。
- 另外，还有选择性的连续三个点号（ … ）用来表示文件结尾。
- 重复的内容可使从参考标记星号 ( * )复制到锚点标记（ & ）。
- 指定格式可以使用两个惊叹号 ( !! )，后面接上名称。
- 文件中的单一文件可以使用指导指令，使用方法是百分比符号( % )。有两个指导指令在YAML1.1版中被定义：
- %YAML 指导指令，用来识别文件的YAML版本。
- %TAG 指导指令，被用在URI的前缀标记。这个方法在标记节点的类型时相当有用。 YAML在使用逗号及冒号时，后面都必须接一个空白字符，所以可以在字符串或数值中自由加入分隔符号( 例如：5,280 或 http://www.wikipedia.org ) 而不需要使用引号。
另外还有两个特殊符号在YAML中被保留，有可能在未来的版本被使用–（ @ ）和（ ` ）。