Origami Specification

The Origami specification outlines the requirements for Origami-compatible components and services. This is a normative specification; non-normative (informative) sections are indicated explicitly or by inset and boxed asides. The words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY have the meaning given to them in RFC 2119.

Overview

This section is non-normative.

Conforming to the Origami specification when building components or services is beneficial for a number of reasons:

• Your code will be easier for other teams who use Origami to understand
• Switching support of your code over to the Origami team will be smoother
• Your component or service will be discoverable, appearing in the Origami Registry

Naming

The name repository refers to a collection of files and folders which are stored in version control (such as Git.

The name component refers to a repository that:

• Provides front end code which can be used as part of a web page
• Complies with the component specification

The name service refers to a repository that:

• Provides code for a web service which can be interacted with over HTTPS
• Complies with the service specification

The name manifest refers to a file in a repository that:

• Has the name origami.json
• Sits at the top of the repository’s directory structure
• Complies with the origami.json manifest specification

Component Specification

A specification which describes what is required for a front-end component to be considered Origami-compatible, and included in our registry. Read the component specification

Service Specification

A specification which describes what is required when building Origami web services. Read the service specification

Origami.json Manifest Specification

A specification which describes the required structure of an Origami.json manifest file. Read the manifest specification