Be capable of understanding the overlap across multiple interface specifications, exploding the JSON schema for each specification into a list of properties to understand what exists across the specs, while also establishing a common vocabular that can be used to understand the space at large.
- Agent 2 Agent
- Agents.json
- Airbyte
- APIs.json
- Arazzo
- AsyncAPI
- JSON Schema
- Model Context Protocol
- NLWeb
- Open Policy Agent (OPA) Rego
- Open Collection
- OpenAPI Overlays
- OpenAPI
- Postman Collection
- Smithy
- Spectral
- Typespec
- Microcks Examples
- API Commons
- FinOps Focus
The Agent2Agent (A2A) Protocol is an open standard for communication and interoperability among independent, often opaque, AI agent systems. Because agents may be built with different frameworks, languagesm and vendors, A2A provides a common language and interaction model.
I wanted to be able to understand how the Agent 2 Agent specification operates.
- Website - https://a2a-protocol.org/latest/
I wanted to flatten and understand all the properties of the Agent 2 Agent specification.
- A2As
- Accepts
- Accepted
- Agents
- Appends
- Artifacts
- Arrays
- Auths
- Authentication
- Authorization
- Bases
- Bearers
- Blockings
- Booleans
- Bytes
- Cancels
- Cancelables
- Capabilities
- Cards
- Chunks
- Clients
- Codes
- Configs
- Configurations
- Configured
- Connects
- Contents
- Context
- Credentials
- Datas
- Defaults
- Deletes
- Descriptions
- Documentation
- Errors
- Events
- Examples
- Extensions
- Files
- Finals
- Flows
- Formats
- Found
- Get
- Headers
- Histories
- HTTP
- Icons
- Ids
- Implicits
- Inputs
- Integers
- Interfaces
- Internals
- Invalids
- JSON
- JSON RPC
- Keys
- Kinds
- Lasts
- Lengths
- Lists
- Messages
- Metadata
- Methods
- Mimes
- Modes
- Mutuals
- Names
- Not
- Notifications
- Nulls
- OAuth
- OpenID
- OpenID Connect
- Operations
- Organizations
- Outputs
- Params
- Parses
- Parts
- Passwords
- Preferred
- Protected
- Protocols
- Providers
- Pushes
- Queries
- References
- Refreshes
- Requests
- Resubscriptions
- Results
- Roles
- Schemes
- Scopes
- Securities
- Sends
- Sending
- Sets
- Signatures
- Skills
- States
- Status
- Streamings
- Strings
- Success
- Supported
- Support
- Tasks
- Texts
- Timestamps
- TLS
- Tokens
- Transports
- Types
- Unknowns
- Unsupporteds
- Updates
- URI
- URL
- Versions
Agents.json is an open-source JSON specification that formally describes contracts for API and AI agent interactions, built on top of the OpenAPI standard.
I wanted to be able to understand how the Agents.json specification operates.
I wanted to flatten and understand all the properties of the Agents.json specification.
- Actions
- Additionals
- Agents
- Arrays
- Bodies
- Booleans
- Contents
- Descriptions
- Examples
- Fields
- Flows
- Ids
- Info
- JSON
- Links
- Names
- Nulls
- Objects
- Operations
- Origins
- Overrides
- Parameters
- Paths
- Properties
- Requests
- Required
- Responses
- Sources
- Strings
- Success
- Targets
- Titles
- Types
- Values
- Versions
Airbyte is an open-source data integration platform that enables organizations to move data from over 600 sources into data warehouses, data lakes, and other destinations.
I wanted to be able to understand how the Airbyte specification operates.
- Website - https://airbyte.com/
I wanted to flatten and understand all the properties of the Airbyte specification.
- Aborts
- Accesses
- Actions
- Adds
- Added
- Additionals
- Adherestos
- Advanceds
- Algorithms
- Allows
- Alwayses
- APIs
- Arrays
- Assertions
- Asyncs
- Auds
- Auths
- Authenticators
- Authentication
- Availabilities
- Backoffs
- Bases
- Baseds
- Basics
- Bearers
- Befores
- Bodies
- Booleans
- Budgets
- Bys
- Calls
- Catalogs
- Cases
- Caches
- Checks
- Chunkings
- Clampings
- Classes
- Clients
- Codes
- Compares
- Completes
- Completeds
- Complexes
- Components
- Composites
- Concurrencies
- Conditions
- Conditionals
- Configs
- Configurations
- Connections
- Connectors
- Consents
- Consts
- Constants
- Contains
- Contents
- Contexts
- Counts
- Countries
- Creations
- Credentials
- Csvs
- Ctys
- Currents
- Cursors
- Customs
- Datas
- Dates
- Datetimes
- Decoders
- Declaratives
- Deduplicates
- Defaults
- Defined
- Definitions
- Delegatings
- Deletes
- Delimiters
- Dependencies
- Describes
- Descriptions
- Details
- Digests
- Directions
- Documentations
- Downloads
- Durations
- Dynamics
- Encodes
- Encodeds
- Encodings
- Ends
- Endpoints
- Entries
- Errors
- Examples
- Exchanges
- Exclusions
- Expirations
- Expires
- Expiries
- Exponentials
- Extracts
- Extractors
- Extras
- Factors
- Faileds
- Failures
- Feeds
- Fetches
- Fields
- Filenames
- Filters
- Filterings
- Firsts
- Fixeds
- Flattens
- Flows
- Fors
- Forms
- Formats
- Froms
- Fulls
- Globals
- Grants
- Graphqls
- Groups
- Groupings
- Gzips
- Handlers
- Headers
- Healths
- Hits
- Https
- Ids
- Identifiers
- Ignores
- Images
- Ins
- Includes
- Increments
- Incrementings
- Incrementals
- Injects
- Inlines
- Inputs
- Integers
- Intervals
- Intos
- Isses
- Iterables
- Items
- Jobs
- Jsons
- Jsonls
- Jwts
- Keys
- Kids
- Lazies
- Legacies
- Levels
- Limits
- Limitings
- Lists
- Loaders
- Logins
- Lookbacks
- Lowers
- Maps
- Mappings
- Matchers
- Maxes
- Maximums
- Merges
- Messages
- Metadatas
- Methods
- Migrations
- Mins
- Minimums
- Movings
- Multiples
- Names
- News
- Nos
- Nones
- Normalizations
- Normalizings
- Numbers
- OAuth
- Objects
- Ofs
- Offsets
- Olds
- Ons
- Options
- Ors
- Origins
- Outputs
- Paginateds
- Paginations
- Paginators
- Pages
- Params
- Parameters
- Parents
- Parametrizeds
- Partitions
- Passphrases
- Passwords
- Paths
- Patterns
- Payloads
- Periods
- Pers
- Plains
- Pointers
- Policies
- Pollings
- Predicates
- Prefixes
- Prereleases
- Primaries
- Priorities
- Profiles
- Properties
- Providers
- Pubsubs
- Queries
- Queues
- Rates
- Ratelimits
- Reads
- Records
- Redirects
- Refs
- References
- Refreshes
- Regexes
- Remainings
- Remaps
- Removes
- Replaces
- Requests
- Requesteds
- Requesters
- Requireds
- Resets
- Resolvers
- Responses
- Retrievers
- Retries
- Routers
- Rules
- Runnings
- Schemas
- Scopes
- Seconds
- Secrets
- Selects
- Selections
- Selectives
- Selectors
- Servers
- Sessions
- Sets
- Sides
- Simples
- Sizes
- Slicers
- Snakes
- Snapshots
- Sources
- Specs
- Specifications
- Starts
- States
- Statuses
- Steps
- Stops
- Strategies
- Streams
- Strictlies
- Strings
- Subs
- Substreams
- Successes
- Suffixes
- Syncs
- Systems
- Tags
- Targets
- Templates
- Texts
- Times
- Timeouts
- Titles
- Tos
- Tokens
- Tombstones
- Transforms
- Transformations
- Types
- Typs
- Underlyings
- Unlimiteds
- Untils
- Updates
- Updaters
- Uploaders
- URL
- URI
- Uses
- Users
- Usernames
- Validates
- Validations
- Validators
- Values
- Versions
- Waits
- Waitings
- Windows
- Xmls
- Zipfiles
APIs.json is a machine-readable specification that API providers use to describe their API operations—much like sitemap.xml describes a - Website. It offers an index of internal, partner, and public APIs that includes not only machine-readable artifacts (OpenAPI, JSON Schema, etc.) but also traditionally human-readable assets such as documentation, pricing, and terms of service.
I wanted to be able to understand how the APIs.json specification operates.
- Website - https://apisjson.org
I wanted to flatten and understand all the properties of the APIs.json specification.
- AIDs
- APIs
- Arrays
- Bases
- Cards
- Commons
- Contacts
- Createds
- Datas
- Descriptions
- Emails
- Fns
- Githubs
- Humans
- Images
- Includes
- Informations
- Keys
- Maintainers
- Medias
- Metas
- Modifieds
- Names
- Networks
- Objects
- Organizations
- Overlays
- Photos
- Properties
- Specifications
- Strings
- Tags
- Tels
- Twitters
- Types
- Unknowns
- URL
- Values
- Vcards
- Versions
- Xs
The Arazzo Specification is a community-driven, open standard within the OpenAPI Initiative (a Linux Foundation Collaborative Project). It defines a programming-language-agnostic way to express sequences of calls and the dependencies between them to achieve a specific outcome.
I wanted to be able to understand how the Arazzo specification operates.
I wanted to flatten and understand all the properties of the Arazzo specification.
- Actions
- Afters
- Arrays
- Bodies
- Booleans
- Components
- Conditions
- Contents
- Contexts
- Criterias
- Criterions
- Depends
- Descriptions
- Expressions
- Extensions
- Failures
- Ids
- Ins
- Infos
- Inputs
- Integers
- Limits
- Names
- Nulls
- Numbers
- Objects
- Ofs
- Ons
- Operations
- Outputs
- Parameters
- Paths
- Payloads
- References
- Replacements
- Requests
- Retries
- Reusables
- Schemas
- Sources
- Specifications
- Steps
- Strings
- Successes
- Summaries
- Targets
- Titles
- Types
- Unknowns
- URL
- Values
- Versions
- Workflows
AsyncAPI is an open-source, protocol-agnostic specification for describing event-driven APIs and message-driven applications. It serves as the OpenAPI of the asynchronous, event-driven world—overlapping with, and often going beyond, what OpenAPI covers.
I wanted to be able to understand how the AsyncAPI specification operates.
- Website - https://www.asyncapi.com
I wanted to flatten and understand all the properties of the AsyncAPI specification.
- Accesses
- Actions
- Additionals
- Addresses
- Alives
- Alls
- Alloweds
- AMQP
- Amqp1s
- Anypointmqs
- APIs
- Arns
- Arrays
- Assertions
- Asymmetrics
- AsyncAPIs
- Attributes
- Auths
- Authentication
- Authorization
- Autos
- Availables
- Avros
- Backoffs
- Bases
- Based
- Bearers
- Bindings
- Booleans
- Budgets
- Bytes
- Calls
- Cases
- Catalogs
- Ccs
- Ccdts
- Channels
- Ciphers
- Cleans
- Cleanups
- Clients
- Codes
- Coms
- Compactions
- Completeds
- Components
- Conditions
- Configs
- Configurations
- Confluents
- Connects
- Connections
- Consts
- Consumers
- Contains
- Contents
- Contexts
- Correlations
- Counts
- Credentials
- Ctys
- Currents
- Datas
- Datetimes
- Deads
- Deduplications
- Defaults
- Defined
- Definitions
- Delays
- Deletes
- Deliverabilities
- Deliveries
- Dependencies
- Depends
- Deprecateds
- Descriptions
- Destinations
- Details
- Digests
- Directions
- Discriminators
- Displays
- Dmqs
- Documentations
- Docs
- Durables
- Durations
- Effects
- Eligibles
- Emails
- Encodings
- Encryptions
- Endpoints
- Enums
- Errors
- Examples
- Exchanges
- Exclusives
- Expirations
- Expiries
- Extensions
- Externals
- Factors
- Factories
- Feeds
- Fifos
- Filters
- Firsts
- Fixeds
- Flows
- Formats
- Formattings
- Froms
- Functions
- Gateways
- Geos
- Globals
- Googlepubsubs
- Grants
- Groups
- GssAPIs
- Handlers
- Headers
- Hearts
- Hosts
- Https
- Ibmmqs
- Ids
- Identifiers
- Ifs
- Ignores
- Implicits
- Ins
- Increments
- Incrementings
- Incrementals
- Indicators
- Info
- Injects
- Inlines
- Integers
- Intervals
- Intos
- Ises
- Items
- Iterables
- Jmses
- Jobs
- Jsons
- Jsonls
- Jwts
- Kafkas
- Keeps
- Keys
- Lasts
- Legacy
- Lengths
- Letters
- Levels
- Licenses
- Limits
- Limitings
- Linkedins
- Lists
- Lives
- Loaders
- Locations
- Logins
- Lookbacks
- Lookups
- Lowers
- Managers
- Mandatories
- Maps
- Mappings
- Matchers
- Maxes
- Maximums
- Maxttls
- Messages
- Methods
- Migrations
- Mins
- Minimums
- Modes
- Modifieds
- Movings
- Mqtts
- Msgs
- Msgvpns
- Msvs
- Multis
- Multiples
- Names
- Namespaces
- Natses
- Negatives
- News
- Nons
- Normalizations
- Normalizings
- Nots
- Nulls
- Nullables
- Numbers
- OAuth
- Oauth2s
- Objects
- Ofs
- Offsets
- Olds
- Ons
- Ones
- OpenAPIs
- OpenID
- OpenID Connect
- Operations
- Options
- Orders
- Orderings
- Origins
- Outputs
- Packets
- Paginateds
- Paginations
- Paginators
- Pages
- Params
- Parameters
- Parents
- Partitions
- Partitioneds
- Passphrases
- Passwords
- Paths
- Pathnames
- Patterns
- Payloads
- Pers
- Periods
- Permitteds
- Persistences
- Phones
- Plains
- Pointers
- Policies
- Pollings
- Predicates
- Prefixes
- Prereleases
- Primaries
- Priorities
- Profiles
- Properties
- Protocols
- Providers
- Pubsubs
- Pulsars
- Queries
- Queues
- Qoses
- Rates
- Ratelimits
- Raws
- Reads
- Records
- Redirects
- Redises
- Redrives
- Refs
- References
- Refreshes
- Registries
- Regexes
- Regions
- Remainings
- Remaps
- Removes
- Replaces
- Replicas
- Replies
- Requests
- Requesteds
- Requesters
- Requireds
- Requirements
- Resets
- Resolvers
- Responses
- Retains
- Retaineds
- Retentions
- Retries
- Retrievers
- Revisions
- Routers
- Routings
- Rules
- Runnings
- Sasls
- Schemas
- Schemes
- Scopes
- Scrambles
- Scrams
- Seconds
- Secrets
- Securities
- Selects
- Selections
- Selectives
- Selectors
- Servers
- Services
- Sessions
- Settings
- Simples
- Sizes
- Slicers
- Snakes
- Snapshots
- Snses
- Solaces
- Sources
- Specs
- Specifications
- Spools
- Sqses
- Starts
- States
- Statements
- Statuses
- Steps
- Stomps
- Stops
- Storages
- Strategies
- Streams
- Strictlies
- Strings
- Subs
- Substreams
- Subjects
- Subscriptions
- Successes
- Suffixes
- Summaries
- Supporteds
- Supports
- Swaggers
- Symmetrics
- Syncs
- Systems
- Tags
- Targets
- Templates
- Tenants
- Terms
- Texts
- Thens
- Times
- Timestamps
- Titles
- Tos
- Tokens
- Tombstones
- Topics
- Transforms
- Transformations
- Traits
- Transports
- Ttls
- Typs
- Types
- Underlyings
- Uniques
- Unknowns
- Unlimiteds
- Untils
- Updates
- Updaters
- Uploaders
- URL
- URI
- Usages
- Uses
- Users
- Usernames
- Userids
- Validates
- Validations
- Validators
- Values
- Variables
- Vendors
- Versions
- Vhosts
- Visibilities
- Vpns
- Waits
- Waitings
- Websockets
- Wills
- Windows
- Wrappeds
- Writes
- Wses
- Xes
- X509s
- Xmls
- Zipfiles
JSON Schema is a vocabulary for annotating and validating JSON documents. It defines the structure. content, and constraints of data—often authored in either JSON or YAML—and can be leveraged by documentation generators, validators, and other tooling.
I wanted to be able to understand how the JSON Schema specification operates.
- Website - https://json-schema.org
I wanted to flatten and understand all the properties of the JSON Schema specification.
- Additionals
- Alls
- Anchors
- Arrays
- Booleans
- Comments
- Consts
- Contains
- Contents
- Defaults
- Defs
- Dependents
- Deprecateds
- Descriptions
- Dynamics
- Elses
- Encodings
- Enums
- Examples
- Exclusives
- Formats
- Ids
- Ifs
- Integers
- Items
- Lengths
- Maxes
- Maximums
- Medias
- Mins
- Minimums
- Multiples
- Names
- Negatives
- Nons
- Nots
- Objects
- Ofs
- Ones
- Patterns
- Prefixes
- Properties
- Reads
- Refs
- References
- Requireds
- Schemas
- Simples
- Strings
- Thens
- Titles
- Types
- Unevaluateds
- Uniques
- Unknowns
- URI
- Vocabularies
- Writes
MCP (Model Context Protocol) is an open protocol that standardizes how applications provide context to large language models (LLMs). It offers a consistent way to connect AI models to diverse data sources and tools, enabling agents and complex workflows that link models to the outside world.
I wanted to be able to understand how the Model Context Protocol specification operates.
- Website - https://modelcontextprotocol.io/
I wanted to flatten and understand all the properties of the Model Context Protocol specification.
- Actions
- Alls
- Annotations
- Arguments
- Arrays
- Ats
- Audiences
- Audios
- Augmented
- Bases
- Blobs
- Blocks
- Booleans
- Calls
- Cancels
- Cancelleds
- Capabilities
- Changeds
- Choices
- Clients
- Codes
- Completes
- Completions
- Consts
- Contents
- Contexts
- Costs
- Creates
- Createds
- Cursors
- Datas
- Defaults
- Definitions
- Deprecateds
- Descriptions
- Destructives
- Dpaths
- Dynamics
- Elicits
- Elicitations
- Embeddeds
- Empties
- Enums
- Errors
- Executions
- Experimentals
- Fields
- Forms
- Formats
- Gets
- Hases
- Hints
- Icons
- Ids
- Idempotents
- Images
- Implementations
- Includes
- Infos
- Initializes
- Initializeds
- Inputs
- Instructions
- Integers
- Intelligences
- Intervals
- Ises
- Items
- Jsons
- Jsonrpcs
- Lasts
- Legacies
- Lengths
- Levels
- Links
- Lists
- Loggings
- Loggers
- Maxes
- Maximums
- Messages
- Metas
- Metadatas
- Methods
- Mimes
- Mins
- Minimums
- Modes
- Models
- Modifieds
- Mores
- Multis
- Names
- Nexts
- Notifications
- Nulls
- Numbers
- Objects
- Ofs
- Ones
- Opens
- Outputs
- Paginateds
- Params
- Payloads
- Pings
- Polls
- Preferences
- Prefixes
- Primitives
- Priorities
- Progresses
- Prompts
- Properties
- Protocols
- Proxies
- Reads
- Reasons
- Refs
- References
- Relateds
- Requests
- Requesteds
- Requireds
- Resources
- Results
- Roles
- Roots
- Samplings
- Schemas
- Selects
- Sequences
- Servers
- Sets
- Singles
- Sizes
- Speeds
- Srcs
- Statuses
- Stops
- Strings
- Structureds
- Subscribes
- Supports
- Systems
- Tasks
- Temperatures
- Templates
- Texts
- Themes
- Titleds
- Tokens
- Tools
- Totals
- Ttls
- Types
- Unknowns
- Unsubscribes
- Untitleds
- Updateds
- URI
- URL
- Uses
- Values
- Versions
- Websites
- Worlds
- Writes
NLWeb simplifies building conversational interfaces for websites. It natively supports the Model Context Protocol (MCP), allowing the same natural-language APIs to serve both humans and AI agents.
I wanted to be able to understand how the NLWeb specification operates.
- Website - https://github.com/nlweb-ai/NLWeb
I wanted to flatten and understand all the properties of the NLWeb specification.
- Additionals
- Agents
- APIs
- Arrays
- Asks
- Booleans
- Clients
- Contents
- Contexts
- Conversations
- Datas
- Formats
- Ids
- Langs
- Locations
- Memories
- Metas
- Mimes
- Modes
- Objects
- Ofs
- Ones
- Prevs
- Prices
- Properties
- Queries
- Requests
- Resources
- Responses
- Returns
- Sites
- Specs
- Streamings
- Strings
- Texts
- Types
- Unknowns
- URI
- Versions
- Whos
OPA (Open Policy Agent) is a general-purpose policy engine that unifies policy enforcement across your stack—improving developer velocity, security, and auditability. It provides a high-level, declarative language (Rego) for expressing policies across a wide range of use cases.
I wanted to be able to understand how the Open Policy Agent (OPA) Rego specification operates.
- Website - https://www.openpolicyagent.org/
I wanted to flatten and understand all the properties of the Open Policy Agent (OPA) Rego specification.
- Aliases
- Annotations
- Arguments
- Arrays
- Assigns
- Authors
- Bodies
- Booleans
- Builtins
- Calls
- Cols
- Comments
- Comprehensions
- Customs
- Decls
- Defaults
- Definitions
- Descriptions
- Dynamics
- Elses
- Emails
- Exprs
- Files
- Functions
- Heads
- Imports
- Integers
- Keys
- Locations
- Modules
- Names
- Negateds
- Objects
- Ofs
- Ones
- Organizations
- Packages
- Paths
- Policies
- Properties
- Refs
- Regos
- Relateds
- Resources
- Results
- Rows
- Rules
- Schemas
- Scopes
- Sets
- Specs
- Statics
- Strings
- Targets
- Terms
- Texts
- Titles
- Types
- Unknowns
- Values
- Variadics
- Variables
- Withs
The OpenCollection Specification is a format for describing API collections, including requests, authentication, variables, and scripts. This specification enables tools to understand and work with API collections in a standardized way.
I wanted to be able to understand how the Open Collection specification operates.
- Website - https://www.opencollection.com/
I wanted to flatten and understand all the properties of the Open Collection specification.
- Accesses
- APIs
- Arrays
- Assertions
- Auths
- Awses
- Bases
- Basics
- Bearers
- Bodies
- Booleans
- Contents
- Datas
- Defaults
- Descriptions
- Digests
- Disableds
- Docs
- Domains
- Enableds
- Encodeds
- Environments
- Expressions
- Files
- Folders
- Forms
- Graphqls
- Grpcs
- Headers
- Hooks
- Https
- Ids
- Items
- Keys
- Methods
- Multiparts
- Names
- Ntlms
- Objects
- Ofs
- Ones
- Operators
- Params
- Passwords
- Paths
- Placements
- Posts
- Pres
- Profiles
- Raws
- Regions
- Requests
- Responses
- Scripts
- Secrets
- Selecteds
- Services
- Sessions
- Strings
- Tests
- Tokens
- Transients
- Types
- Unknowns
- URL
- Urlencodeds
- Usernames
- Values
- Variables
- Variants
- V4s
- Wsses
The Overlay Specification is an auxiliary standard that complements the OpenAPI Specification. An OpenAPI description defines API operations, data structures, and metadata—the overall shape of an API. An Overlay lists a series of repeatable changes to apply to a given OpenAPI description, enabling transformations as part of your API workflows.
I wanted to be able to understand how the OpenAPI Overlays specification operates.
I wanted to flatten and understand all the properties of the OpenAPI Overlays specification.
- Actions
- Arrays
- Booleans
- Descriptions
- Extends
- Extensions
- Infos
- Nulls
- Numbers
- Objects
- Overlays
- Removes
- Specifications
- Strings
- Targets
- Titles
- Unknowns
- Updates
- Versions
The OpenAPI Specification (OAS) is a formal standard for describing HTTP APIs. It enables teams to understand how an API works and how multiple APIs interoperate, generate client code, create tests, apply design standards, and more.
I wanted to be able to understand how the OpenAPI specification operates.
- Website - https://www.openapis.org
I wanted to flatten and understand all the properties of the OpenAPI specification.
- Allows
- APIs
- Arrays
- Authorization
- Bearers
- Bodies
- Booleans
- Callbacks
- Clients
- Codes
- Components
- Contacts
- Contents
- Credentials
- Defaults
- Deletes
- Deprecateds
- Descriptions
- Dialects
- Documentations
- Docs
- Emails
- Encodings
- Enums
- Examples
- Explodes
- Externals
- Flows
- Fors
- Forms
- Gets
- Heads
- Headers
- Https
- Identifiers
- Implicits
- Ins
- Infos
- Items
- Jsons
- Licenses
- Links
- Maps
- Medias
- Names
- OAuth
- Objects
- Ofs
- Oidcs
- OpenAPIs
- Operations
- Options
- Parameters
- Patches
- Paths
- Passwords
- Posts
- Puts
- Refs
- References
- Refreshes
- Requests
- Requireds
- Requirements
- Reserveds
- Responses
- Schemas
- Scopes
- Securities
- Servers
- Services
- Specifications
- Strings
- Styles
- Summaries
- Tags
- Terms
- Titles
- Tokens
- Traces
- Types
- Unknowns
- URL
- Values
- Variables
- Versions
- Webhooks
A Postman Collection is a portable JSON artifacts that organizes one or more API requests—plus their params, headers, auth, scripts, and examples—so you can run, share, and automate them in the Postman desktop or web client application. Collections can include folders, collection- and environment-level variables, pre-request and test scripts, examples, mock server definitions, and documentation.
I wanted to be able to understand how the Postman Collection specification operates.
- Website - https://postman.com
I wanted to flatten and understand all the properties of the Postman Collection specification.
- Ages
- API Keys
- Arrays
- Attributes
- Auths
- Awsv4s
- Basics
- Bearers
- Behaviors
- Bodies
- Booleans
- Certs
- Certificates
- Codes
- Contents
- Cookies
- Descriptions
- Digests
- Disableds
- Domains
- Edgegrids
- Events
- Execs
- Expires
- Extensions
- Files
- Forms
- Formdatas
- Graphqls
- Groups
- Hashes
- Hawks
- Headers
- Hosts
- Https
- Ids
- Identifiers
- Infos
- Integers
- Items
- Keys
- Lists
- Listens
- Majors
- Matches
- Maxes
- Metas
- Methods
- Minors
- Modes
- Names
- NOAuth
- Ntlms
- Nulls
- Numbers
- Oauth1s
- Oauth2s
- Objects
- Ofs
- Ones
- Onlies
- Options
- Originals
- Passphrases
- Patches
- Paths
- Ports
- Postmans
- Profiles
- Protocols
- Proxies
- Queries
- Raws
- Requests
- Responses
- Schemas
- Scripts
- Secures
- Sessions
- Srcs
- Statuses
- Strings
- Systems
- Times
- Timings
- Tunnels
- Types
- Unknowns
- URL
- Urlencodeds
- Values
- Variables
- Versions
Smithy is a protocol-agnostic Interface Definition Language (IDL) and set of tools developed by Amazon for generating clients, servers, documentation, and other artifacts AWS. The Smithy IDL features an intuitive syntax built on best practices from years of experience creating services and SDKs across multiple programming languages.
I wanted to be able to understand how the Smithy specification operates.
- Website - https://smithy.io/
I wanted to flatten and understand all the properties of the Smithy specification.
- Applies
- Arrays
- Collections
- Creates
- Deletes
- Enums
- Errors
- Identifiers
- Inputs
- Ints
- Keys
- Lists
- Maps
- Members
- Metadatas
- Mixins
- Objects
- Operations
- Outputs
- Properties
- Puts
- Reads
- References
- Renames
- Resources
- Services
- Shapes
- Simples
- Smithies
- Strings
- Structures
- Targets
- Traits
- Types
- Unions
- Unknowns
- Updates
- Values
- Versions
Spectral is an open-source API linter for enforcing style guides and best practices across JSON Schema, OpenAPI, and AsyncAPI documents. It helps teams ensure consistency, quality, and adherence to organizational standards in API design and development.
I wanted to be able to understand how the Spectral specification operates.
- Website - https://github.com/stoplightio/spectral
I wanted to flatten and understand all the properties of the Spectral specification.
- Aliases
- Alls
- Arrays
- Descriptions
- Diagnostics
- Dirs
- Documentations
- Duplicates
- Extends
- Fields
- Formats
- Functions
- Givens
- Humans
- Incompatibles
- Keys
- Objects
- Ofs
- Ones
- Options
- Overrides
- Parsers
- Paths
- Readables
- Rules
- Rulesets
- Severities
- Strings
- Thens
- Unknowns
- URL
- Values
TypeSpec is a language for defining cloud service APIs and shapes. TypeSpec is a highly extensible language with primitives that can describe API shapes common among REST, OpenAPI, gRPC, and other protocols.
I wanted to be able to understand how the TypeSpec specification operates.
- Website - https://typespec.io/
I wanted to flatten and understand all the properties of the TypeSpec specification.
- Aliases
- Applications
- Arguments
- Arrays
- Booleans
- Constraints
- Decorators
- Defaults
- Elements
- Enums
- Extends
- Imports
- Interfaces
- Is
- Kinds
- Members
- Models
- Names
- Namespaces
- Objects
- One
- Operations
- Optionals
- Parameters
- Properties
- References
- Returns
- Spreads
- Strings
- Subs
- Targets
- Templates
- Types
- Unions
- Unknowns
- Values
- Variants
APIExamples format is Microcks’ own specification format for defining examples intended to be used by Microcks mocks.
I wanted to be able to understand how the Microcks APIExamples specification operates.
I wanted to flatten and understand all the properties of the Microcks APIExamples specification.
- APIs
- Bodies
- Events
- Examples
- Headers
- Items
- Kinds
- Medias
- Messages
- Metadatas
- Names
- Objects
- Operations
- Pairs
- Parameters
- Payloads
- Requests
- Responses
- Statuses
- Strings
- Types
- Unidirectionals
- Unknowns
- Versions
API Commons is a collection of open-source building blocks for API operations. It began as a machine-readable way to define the parts of an API, and works in concert with APIs.json to translate human-readable aspects of your API program into machine-readable artifacts that can standardize and automate your ecosystem.
I wanted to be able to understand how the API Commons specification operates.
- Website - https://apicommons.org/
I wanted to flatten and understand all the properties of the API Commons specification.
- APIs
- Arrays
- Attributions
- Authors
- Booleans
- Businesses
- Changes
- Dates
- Definitions
- Descriptions
- Discussions
- Domains
- Elements
- Engines
- Entries
- Experiences
- Frames
- Geo
- Guidances
- IDs
- Images
- Integers
- Interfaces
- Labels
- Licenses
- Lifecycles
- Limits
- Links
- Logs
- Maps
- Metrics
- Multiplieds
- Names
- Numbers
- Objects
- Peoples
- Plans
- Policies
- Prices
- Properties
- Rates
- Researches
- Roads
- Rules
- Scopes
- Slugs
- Specifications
- Strings
- Subtitles
- Tags
- Technologies
- Times
- Titles
- Types
- Units
- Updateds
- URL
- Users
- Visibilities
FinOps Open Cost & Usage Specification is an open specification that normalizes billing datasets across cloud, SaaS, data center, and other technology vendors to reduce complexity for FinOps Practitioners.
I wanted to be able to understand how the FinOps Focus specification operates.
- Website - https://focus.finops.org/
I wanted to flatten and understand all the properties of the FinOps Focus specification.
- Account
- Availability
- Billed
- Billing
- Category
- Charge
- Code
- Commitment
- Cost
- Currency
- Date
- Description
- Discount
- Effective
- End
- Format
- Frequency
- Id
- Invoice
- Issuer
- Key
- List
- Name
- Null
- Number
- Numeric
- Object
- Period
- Price
- Pricing
- Provider
- Publisher
- Quantity
- Region
- Resource
- Service
- Sku
- Start
- String
- Sub
- Subcategory
- Tags
- Time
- Type
- Unit
- Unknown
- Usage
- Value
- Zone
JSON-RPC is a stateless, light-weight remote procedure call (RPC) protocol. Primarily this specification defines several data structures and the rules around their processing. It is transport agnostic in that the concepts can be used within the same process, over sockets, over http, or in many various message passing environments. It uses JSON (RFC 4627) as data format.
I wanted to be able to understand how the JSON RPC specification operates.
- Website - https://www.jsonrpc.org/specification
I wanted to flatten and understand all the properties of the JSON RPC specification.
- jsonrpc-version
- id
- method
- params
- error
- request
- notification
- response-success
- response-error
- response
- batch-request
- batch-response
- code (within error)
- message (within error)
- data (within error)
- jsonrpc (within nested objects)
- result (within response-success)
Across these twenty specifications I have begun to aggregate the specification specific properties to better understand the common and overlapping aspects of what these specifications do and how they are managed.
These are priorities aggregated across the specifications, identifying the important parts they share within the specifications themselves, ordered by spec usage.
- Versions
- Properties
- Examples
- Operations
- References
- Requests
- Defaults
- Keys
- Content
- Paths
- URLs
- Headers
- URIs
- Targets
- Data
- Methods
- Parameters
- Responses
- Schema
- Sources
- Extensions
- Formats
- Specifications
- Authentication
- Bodies
- Context
- Flows
- Info
- Queries
- Updates
- Tokens
- Actions
- Codes
- Credentials
- Files
- Inputs
- Metadata
- Messages
- Configurations
- Definitions
- Protocols
- Servers
- Additionals
- Agents
- APIs
- Authorization
- Clients
- Enums
- Errors
- Mime-Types
- Passwords
- Providers
- Resources
- Scopes
- Services
- Bases
- Documentation
- Events
- Functions
- Imports
- Links
- Modes
- Outputs
- Profiles
- Results
- Status
- Usernames
- Variables
- Maximums
- Prefixes
- Streams
- Templates
- Bearers
- Components
- Deletes
- Filters
- Identifiers
- Minimums
- Multiples
- Options
- Removes
- Required
- Rules
- Secrets
- Tags
- Users
- Aliases
- Alls
- Capabilities
- Deprecated
- Fields
- Groups
- Images
- Limits
- Mappings
- Metadata
- Origins
- Policies
- Selections
- Sets
- States
- Systems
- Unions
- Validates
- Annotations
- Arguments
- Bindings
- Calls
- Channels
- Counts
- Directions
- Encodings
- Externals
- Forms
- Hosts
- Includes
- Interfaces
- Lengths
- Licenses
- Locations
- Logs
- Members
- Models
- Namespaces
- Notifications
- Organizations
- Overrides
- Pages
- Payloads
- Patterns
- Ports
- Priorities
- Reads
- Regions
- Renames
- Retries
- Scripts
- Selectors
- Sessions
- Severities
- Shapes
- Simples
- Sizes
- Skills
- Specs
- Starts
- Steps
- Structures
- Subjects
- Successes
- Summaries
- Supports
- Tasks
- Timestamps
- Traits
- Validations
- Variants
- Writes
- Accepts
- Accesses
- Applies
- Artifacts
- Attributes
- Backs
- Bytes
- Cards
- Cases
- Collections
- Comments
- Conditionals
- Connections
- Constraints
- Consumers
- Contacts
- Cookies
- Creates
- Cursors
- Customs
- Dates
- Decorators
- Depends
- Destinations
- Details
- Digests
- Disableds
- Domains
- Durations
- Elements
- Emails
- Enables
- Ends
- Endpoints
- Entries
- Exchanges
- Exclusives
- Explodes
- Expressions
- Extends
- Factors
- Folders
- Globals
- Grants
- Handlers
- Histories
- Incrementals
- Injects
- Inlines
- Intervals
- Jobs
- Kinds
- Levels
- Loaders
- Logins
- Media
- Migrations
- Offsets
- Optionals
- Overlays
- Packages
- Prompts
- Proxies
- Queues
- Roles
- Transformations
This provides a top-level vocabulary that could be further used to begin working schema, mapping objects and properties, as well as helping inform a new schema work.
This work is ongoing, with additional steps needed to better understand what is happening across these specifications, and better understand what the incentives are for this research.
- Operations - Need to continue profiling each of the specs and how they operate, providing more detail regarding how they are managing the ecossytem and community.
- Examples - Need to publish examples for each of the specifications, ideally multiple examples to help understand the implicit or explicit nature of each schema.
- Adoption - Quantity the adoption of each standard in some common way to understand where it is used and applied as part of regular enterprise operations.
- Governance - I still do not have a common way of expressing what the governance models is behind each of these to understand how decisioins are made on road map.
- Policies - Develop the policies and rules to allow for further automation fo governance across implementations of these schema as part of integrations.
- Schema - Individual schema could be organized and compared on the individual property level to understand the applies to oranges comparison of each object.
- Mappings - One could map individual objects and properties across the schema to be able to potentially translate across them.
I am going to just sit on this over the holidays, gather more feedback, and think about other ways that I can work to connect the dots here and inform existing activities across the specs or inform any new spec work.
As I dive into each specification I have questions, and will keep aggregating the questions here and starting some as issues to drive further discussions around and across each spec, it's operations, and the individual details.
- Schema for TypeSpec and Smith are fabricated--there isn't an official one, but all the rest have formal JSON Schema.
- I may break these up into other domains based upon policy / rules and financial operations, but still deciding
- I would like to add platform schema definitions to help add this layer, but may do as another domain.
I will be creating issues for some of these questions, but feel free to start them or ask any new questions via issues or pull requests--this is an open converstionf or anyone who wants to get involved and contribute.