Provides a common reference and API end-point specification for implementing Cannabis Data Systems.
The world of cannabis regulatory compliance is getting complex and large. There are numerous vendors, each with a common goal but a unique API. The goal of this interface is to provide a basis for data interoperability.
An important first step for bringing the industry together is to start talking in with common terms, a second is a common interface.
The OpenTHC API Specification aims to describe one part of this standard.
The OpenTHC CRE, Bunk, Data, Dump, Menu, P2P, Pipe, QA and other services implement these interfaces.
It's our hope that others in the cannabis industry could adopt, in whole or in part, some of the concepts and designs we've published.
The OpenTHC API Module provides a method for reading/writing to an OpenTHC Compatible system. A set of standard base data models for objects in the Cannabis Industry.
This API was heavily influenced by the Open API Initiative and the Data Transfer Project
- Use International System of Units for weight and volume values.
- Use ISO-8601 for date and time values.
We provide some base data examples and JSON schema.
The documentation has been createded using a combination of Asciidoc and Swagger.
Asciidoc is in [./doc], Swagger sources are in [./swagger]
make docs
We've been using Asciidoctor over Asciidoc for generating the outputs. Our Makefile supports both, but one, or the other may be missing features (such as PlantUML).
A JSON Schema is published for all the objects in this system, they are located in ./json-schema These files are constructed from the YAML documentation in ./swagger Sample objects are provided in ./json-sample
make json-schema
There is a bunch of "core" data for this industry, Company, License, Variety, Product Type and Laboratory Metrics. Included in the ./etc directory are pre-populated tables for these values. Usage of common, unique identifiers for data-fields we all care about will improve interoperablity.
Run the unit tests in ./test
make test
You could also use Prism for running a mock interface.
This thing depends on Asciidoc/Asciidoctor (Python, Ruby) and some build scripts (JS, PHP, Ruby)
apt-get install ruby-bundler ruby-dev
bundle install --path vendor/bundle