The AgTech API (ATA) Specification is a community-driven open specification within Open AgTech, a collaborative community of technology professionals dedicated to improving technology in agriculture. ATA defines a standard, programming language-agnostic interface description for REST APIs, which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code or inspection of network traffic. When an API conforms to ATA, a consumer can understand and interact with the remote service with a minimal amount of implementation logic. Similar to what interface descriptions have done for lower-level programming, ATA removes guesswork in calling a service. Use cases for machine-readable API definition documents include, but are not limited to: interactive documentation; code generation for documentation, clients, and servers; and automation of test cases. ATA documents describe an API's services and are represented in either YAML or JSON formats. These documents may either be produced and served statically or be generated dynamically from an application.
The current version of the AgTech API Specification is Version 0.0.1. The next version will be 0.0.2.
If you just want to see it work, check out the list of current examples.
Development of ATA is guided by the Technical Steering Committee (TSC). All development activity on the future specification will be performed as features and merged into this branch. Upon release of the future specification, this branch will be merged to master. The TSC holds weekly web conferences to review open pull requests and discuss open issues related to ATA. Participation in weekly calls and scheduled working sessions is open to the community. Open AgTech encourages participation from individuals and companies alike. If you want to participate in the evolution of ATA, consider taking the following actions:
- Review the current specification, in master.
- Review the development process so you understand how the spec is evolving.
- Check the issues and pull requests to see if someone has already documented your idea or feedback on the specification. You can follow an existing conversation by adding a comment to the existing issue or PR.
- Create an issue to describe a new concern. If possible, propose a solution.
- Open a PR related to your issue or concern. This will be reviewed and merged by the TSC.
Not all feedback can be accommodated and there may be solid arguments for or against a change being appropriate for the specification.