Transport Specifications

Proposals are organized into sections based on their underlying protocol, for example the RESO Web API.

Specifications are divided into modular endorsements, each of which are offered separately through RESO Certification.

RESO Endorsements use Semantic Versioning.

Please visit our discussion forum if you have any questions, or open an issue if you have a new feature request.

RESO Web API

The following proposals use the RESO Web API as a transport mechanism.

Data Dictionary Endorsement

Status: Adopted, Current Version: 1.7

The Data Dictionary endorsement defines models for use in the RESO domain. These include Resources, Fields, Lookups, and Relationships between Resources.

Payloads Endorsement

Status: Adopted, Current Version: 1.7

Defines general payloads data availability testing rules, as well as the IDX Payload Endorsement.

Web API Core Endorsement

Status: Adopted, Current Version: 2.0.0

The Web API Core endorsement defines the primary functionality RESO Web API servers are expected to have in order to provide both replication and live query support.

Web API Add/Edit Endorsement

Status: In Review by the RESO Certification Subgroup

The Web API Add/Edit endorsement defines how to Create, Update, and Delete data in the RESO Web API.

Web API Validation Expression Endorsement

Status: In Transport Backlog

Web API Validation Expressions allow for the transport of machine-executable business rules using the RETS 019 Validation Expression grammar.

Related Documents

The following documents may also be helpful:

• RESO DDWiki
• RESO Data Dictionary 1.7 Reference Spreadsheet
• RESO Commander

New Change Proposals

RCP Template

If you would like to suggest a new change proposal, please use the RCP Template in this repository and fill in each section accordingly.

Submission Process

The process for submitting a new proposal is as follows:

• Create a new branch for the proposal by choosing the next available RCP number.
  • The branch name should be created from the RCP number and use a short and meaningful name so others understand what the proposal does.
  • It should also include the current version of the proposal affected.
  • If the change proposal affects an existing version, a tag should be included specifying whether the proposed changes result in a major, minor, or patch level change to the existing spec.
  • Example: rcp-040-fancy-new-web-api-feature-2.0.0-major.
• Use the RCP Template to create a change proposal.
• When the proposal is ready for review, create a Draft PR so that it may be reviewed by the community and chairs.
• If adopted, the proposal will be merged into the main branch.

Please contact RESO Development if you have any questions.