Change Log

This is a detailed log of the changes that have been made to the Drone over time. We try to keep a log of all changes here to keep a history of everything that has happened. This also acts as the story of the platform, helping share the thought that goes into the platform, so that other providers can help follow.

Have an idea for drone API (Definition) - I want to explore what is possible with developing a drone API without the actual work of having to develop one and invest too much time and resources.
Dump data from drone platform (Definition) - I pulled data from the drone platforms I use to get an idea for the type of data, media, and other bits are in play. I wanted to use this as the blueprint for what I was doing with my prototype.
Identify the schema for data (Definition) - I went through all the ata and created JSON schema for all the data I wanted to keep, identifying and organizing the important bits that I wanted to keep and make part of the drone API.
Create an OpenAPI for API (Definition) - I created an OpenAPI definition with details of all of the APIs I wanted to create to access and manage the data I have outlined in my schema.
Setup Github Organization (Management) - All APIs start with Github in my world, so I setup an organization for this operation, giving me an area to publish all the projects underneath this umbrella.
Setup Definition Repository (Definition) - I setup a Github repository for storing all the definitions associated with the drone API, setting it up for both human and programmatic consumption through the lifecycle of this API.
Guide (Definition) - I created a guide outlining all the definitions used as part of the drone API, providing a single place to find all definitions for the project, and hang any new definitions generated in future work.
Versioning (Design) - We needed to make a decision around how we handle the version of the API. Are we going to do in the header, in url, or are we going to rely on the design of our API to handle versioning for us, making it something we aren't going to do?
Paths (Design) - Establish structure and guidance for how all paths are crafted for APIs deployed across the platform. Specifically using plain english words that describe what each resource does, following common elements of a RESTful approach.
Verbs (Design) - What is the verb strategy? How are we using POST, PUT, and DELETE as well as GET. What is the POST v PUT strategy? How are we handling OPTIONS, and HEAD? We need a standard approach.
Actions (Design) - Beyond the basic verbs provided us how will we be handling more advanced actions? What are the path and verb strategies for tackling more complex transformations involving the API resources we are making available.
Parameters (Design) - What are the common parameters we are using across all available API paths? Let's think through the parameters as part of our overall schema definition strategy, and reference them using JSON schema references in the OpenAPI for the project.
Headers (Design) - Similar to parameters, what is our header strategy? Let's educate ourselves about the common headers out there, as well as some of the lesser known headers that might contribute to other areas of our API design. Let's organize them as part of our larger schema definition in the OpenAPI.
Body (Design) - We are setting the standard for how we are using the body across all our API calls. Are all POST and PUTs using the body. How are we handling file uploads and the upload and downloading of heavy objects used across our API design.
Pagination (Design) - What is the standard approach to doing pagination across API responses? Are we considering hypermedia in this process? Are we going a simpler route and following an existing standard from an API that is well known? Establish the standard for pagination of large datasets.
Schema Filtering (Design) - What is the standard for allowing the actual schema returned in API responses to be filtered, minimized, or expanded? Allowing for API consumers to specify how little, or how much data they received. Are we considering a more holistic approach using GraphQL. Do we want our consumers to have this control, or will we be handling in our API design.
Data Filtering (Design) - Beyond the schema, what approaches to allowing API consumers to filter data that is returned. Searching, filtering, and other approaches to allowing consumers to get exactly the data they need.
Sorting (Design) - How will data be sorted? Is this an area we are looking at GraphQL or more holistic approach, or do we have a simpler approach, following the lead of popular APIs, using sorting patterns that developer are already used to.
Granularity (Design) - Have we stepped back and look at the granularity of API paths and definitions? Are things small, modular, well thought out, and provide valuable units of compute?
Simplicity (Design) - Are things simple? Has complexity been reduced? Are all aspects of the design intuitive and quick to understand what is possible? Let's focus on simplicity across every aspect of the design.
Readability (Design) - Always review the API design and check for readability. Can you scan the design and understand what is going on. Naming, summary, and description are always plain english and meant more for humans than for computers.
Relationships (Design) - Have we evaluated and considered the relationships between our APIs and the resources we are making available. Are the relationships represented in the design of our API?
Status (Design) - Take the time to evaluate the HTTP status codes returned across ALL API requests. Are there more than just 200, 404, and 500 status codes available, helping other systems truly understand what is going on with API responses.
Errors (Design) - Along with proper HTTP status codes is there a common definition model defined to represent all errors that will be returned as part of API responses. Is this definition represented in the OpenAPI with associates with each individual API response definition.
Media Types (Design) - Is there a clear media type strategy in place outline what media types the API will accept and respond with? Is content negotiation built into the original design of the API, even if single media types are available in early versions? Ideally all APIs respond with HTML, XML, JSON, and even CSV to support a wide range of applications.
Hypermedia (Design) - What research has gone into leading hypermedia formats, contributing to the overall design discussion for this API? Each API should evaluate the benefits hypermedia would bring to the design and functionality as part of the design process.
Standards (Design) - What other standards are missing from the design of our APIs and underlying schema? Have we considered existing schema like, and are we using common standards for dates, currencies, and other elements of the design? Take time to understand what standards already exist and avoid reinventing the wheel whenever possible.
Update OpenAPI (Definitions) - Take everything we've learned and applied to the API's design and make sure the OpenAPI reflects the API design change log, providing a machine readable definition of the API surface area that has been hammered out as part of this process.
Guide (Design) - Take a moment and gather up all the decisions made throughout the API design process, and cumulatively with each API this process is applied, and document them in a guide for standardization across all teams. The guide should be evolved as the design process changes, and be published where all team members can access and contribute, and even shared publicly when it makes sense.
Platform (Deployment) - Identify which platform(s) APIs will operate in. Either AWS, Google, Azure, Heroku, or other, have a standard approach to account management, billing, and the deployment and operation of resources. Establish standard, and put in practice for deploying the database, DNS, compute, and other essential resources used throughout the API lifecycle.
Database (Database) - Setup and configure the database or databases for the backend of our API using the schema designs we've accumulated so far.
Server (Deployment) - Identify the server platform to be used and setup then configure an instance in support of API operations. This could also be leading examples of serverless environments, and leading edge approaches to deploying code these days.
DNS (DNS) - Establish which DNS platform will be used to support APIs, and establish a plan for setting up, configuring, and managing DNS in support of API operations.
Framework (Deployment) - Research the available API deployment frameworks for the programming languages we have resources available in, and choose the right framework(s) for use in deploying any API--establish common practices for deploying APIs from start to finish.
Identify a host (DNS) - Establish a host for use across API operations, for base_URL, developer portal, and other supporting resources.
Identify a base URL (DNS) - Establish a base URL for the API, serving as the root of all API calls--keeping it clean and simple.
Guide (DNS) - Stop and establish a guide to DNS for the platform. Even if the same domain or subdomain is used, provide guidance on how new subdomains are setup, and how supporting projects work. Include the details of logging, monitoring, and other aspects of DNS as it overlaps with API operations.
Thinking about encryption (Encryption) - Consider encryption for EVERYTHING across API operations, making it default for anything in transport in support of the API.
Thinking about CORS (Deployment) - Make sure we have CORS enabled. We aren't running a website, we need things to be available across domains. Consider locking down to approved application list if security is a concern.
Server Skeleton (Deployment) - Take the OpenAPI and generate server skeletons in the programming and platform of choice. Doing the heavy lifting of developing each API, while keeping things in check with the latest edition of the OpenAPI.
Artisan Finish (Deployment) - Take even more time to polish each endpoint for the API, wiring things up to the database, algorithms, and other resources that will be being served up as part of API operations.
Guide (Deployment) - Take the time to pause and document everything accomplished as part of the development process, coming up with a standard approach deploying APis across all operations. Publish the guide where everyone involved with development can get at it.
API Management (Management) - Take a look at the latest list of API management providers and pick one of the ones that suit the needs of this project. I recommend going with Tyk if you are looking for an open source modular solution, or 3Scale, Dreamfactory, and Restlet if you are looking to deploy in the cloud.
Authentication Strategy (Authentication) - What is the authentication strategy. Let's lightly key up data and content that is light security, allowing for easy access by developers. All personally identifiable information (PII) should be secured using OAuth 2.0, and all applications need to leverage OAuth for identity and access management.
Acquisitions Costs (Monetization) - What were the acquisition costs associated with gathering the data, processing the schema, and the API definition.
Developer Cost (Monetization) - What costs were involved with developing the platform, server, framework, and other aspects of setting up. Identifying all the costs associated with the development of each API.
Operational Cost (Monetization) - Now, what does it cost to operate each API from the database to the DNS frontend. Establish a baseline for operating each API each day or month, for evaluation across all stops along the way.
Direct Value (Monetization) - Take time to consider what the direct value generated by each API is. API calls, transactions, click through traffic, or any other easily measured value generated by APIs existing. Gather these definitions in a list to better understand what is being generated.
Indirect Value (Monetization) - Think beyond the direct value being generated and think about some of the indirect aspects of API operation like brand awareness, social media and website exposure. There are many ways that an API will generate value for the drone and other resources available here.
Unit of Value (Plans) - What units of value are being exchanged here. Not all the drone data, media and other units being exchanged will be of value here, but others will be of great interest to a variety of different users. Identify a list of all resources, and what their value to consumers is perceived as.
Timeframes (Plans) - What time frames are we dealing in? Are we measuring by the second, minute, day, week, month, or quarter. Which APIs are we measuring and what are their timeframes--how does this impact billing?
Metrics (Plans) - How are we measuring value exchange? Are we measuring by the API call, by the transaction, or maybe MB download or in transit? Are we charging by user, or the amount of storage and compute? Develop a list of metrics that will be used to measure ALL API calls.
Limits (Plans) - Where are there limits. Where is the ceiling with performance and scalability? What limitations are imposed on new accounts, and what do access levels look like for partners? Develop a list of all the limitations on infrastructure, and API access.
Regions (Plans) - What regions are available for accessing the API? Depending the platform(s) used there should be a range of geographical regions we can make available to API consumers? Deploying permanently or temporarily into cloud infrastructure in any given region, and include that as part of plans and pricing.
Features (Plans) - What are all the features offered as part of API access? We need a master list of features, and which APIs and/or plans they are associated with. Some features are default, while others are designed to incentivize longer engagements and increased usage.
Access Tiers (Plans) - While each individual API should have its own value measurement, timeframes, metrics, and limits applied, we should be considering tiers of access for the public, for partners, and even internally. Each tier can possess one or many APIs, and employ a variety of limitations on access to these resources. Provide a strategy for how plans are defined, and executed.
Guide (Plans) - Stop and document everything about the value and monetization strategy involved with operations, and how that translates into the timeframes, metrics, limits, regions, features, and access tiers. Document, share, and keep updated, using it to guide platform operations.
Configure API management (Management) - The API management solution will need to be configured to reflect the plans and service composition established. The API management layer will be the broker of the plan, and making sure the API contract is in alignment with business objectives.
Logging (Logging) - Establish a logging strategy beyond what is offered as part of API management and logging of the API. Combine database, server, DNS, and API management into a single logging strategy for integration and analysis as part of API operations.
Logging API (Management) - Launch an API to provide access to the logging layer of the API platform. While this may not be made available to average users, it will be valuable for security, and other internal operations.
Guide (Logging) - Stop and document the logging layer, providing details on how logs are collected, aggregated, stored, and accessed via the API layer, providing a single place to go when trying to understand what is gathered by default across API operations.
Reporting (Management) - With all the moving parts in place let's set up reporting across the API management, logging, and other aspects of operations, providing information about API consumption internally as well as to partners, and consumers.
Registration (Management) - Establish a registration system for the platform, requiring users to sign up before they can access any API resources.
Github Auth (Authentication) - Provide the option for users sign up with their Github account, eliminating the need to create yet another password.
Twitter Oauth (Authentication) - Provide the option for users sign up with their Twitter account, eliminating the need to create yet another password.
Facebook Auth (Authentication) - Provide the option for users sign up with their Facebook account, eliminating the need to create yet another password.
Google Auth (Authentication) - Provide the option for users sign up with their Google account, eliminating the need to create yet another password.
Acceptance (Management) - Establish what the acceptance policy looks like. Are developers immediately given access to resources. Which plan are they put into, or maybe they need approval before making more than X calls. Identify and document what the acceptance policy for registration is.
Signup Email (Management) - Provide a signup email upon registration, providing users with all the details they will need to get access, while also verify the validity of the signup.
Github Repo For Portal (Portal) - Using the Github organization for the project, add another repo, but this time for the developer portal.
Github Page for Portal (Portal) - Setup Github Pages for the repository, and select a nice looking template for the developer portal.
Portal URL (DNS) - Setup a subdomain for the portal using, providing a single location to access the API platform.
Description (Portal) - Write a simple description detailing what the drone API will be delivering, and what the purpose of the platform is.
Generate documentation from OpenAPI (Documentation) - Generate API documentation using the OpenAPI, with one of the open source solutions like Swagger UI or Redoc.
Generate SDKs / Libraries from OpenAPI (SDK) - Generate SDKs and other code samples from the OpenAPI for the project, and keep them update to date with changes made with each version.
Code Page (Portal) - Setup a page within the portal for publishing all SDKs and other code related resources.
Getting Started Page (Portal) - Set Up a getting started page outlining exactly the steps to follow when getting up and running with the platform.
Authentication Page (Portal) - Setup an authentication page outlining what the platform will require for authentication, when making any requests to the API.
FAQ Page (Portal) - Set Up an FAQ page listing all of the common questions that get asked by partners, consumers, and other users of the platform.
Support Channels (Support) - identify what support channels will be used to engage with partners and consumers of the platform. We want to provide as much support as we can, but keep things in alignment with what resource we have available, and the demand on the platform.
Support Page (Portal) - Publish a support page sharing all the support channels, and whatever other information is available for partners and consumers when they need help.
Road Map Page (Portal) - Publish a page sharing the road map, providing consumers with as much information about where the platform is headed.
Issues Page (Portal) - Publish a page showing any open issues regarding platform operations, being as transparent as possible with what is going on.
Change Log Page (Portal) - Publish a page showing all the changes made to the platform, providing a natural flow from the road map to the change log, keeping a clear record of everything that has happened.
Developer dashboard (Management) - Publish a private dashboard for authenticated users to access a summary of their engagement with the platform.
Developer message (Management) - Provide a messaging system for partners and consumers, even if it is done via Github issues or even email.
Developer applications (Management) - Leveraging the API management solution allow users to add, update, and retire applications that are being integrated with the platform.
Developer plans (Management) - Provide a way for developers to change the plans they are in based upon the overall API plan for operations established earlier.
Developer usage analytics (Management) - Publish API usage analytics for developers to access and see what their consumption looks like, and how this impacts their bill, and reflects the plan they are operating within.
Developing billing (Management) - Provide tools for developers to manage their usage and billing, helping them understand what their are paying, and projecting what things will cost.
Password reset (Management) - Allow developers to reset their passwords using a common flow used by major providers -- do not reinvent the wheel.
Two Factor Authentication (Authentication) - Enable two factor authentication for the developer accounts requiring code usage of authenticator code before there can be a password change.
Delete account (Management) - Allow developers to delete their account and terminate their relationship with the platform.
Guide (Management) - Stop and document the API management wolkow, documenting all the tools involved, and what the processes are across the portal, developer dashboard, and any other management interfaces.
Terms of Service (Terms of Service) - Publish a plain english terms of services for consumers to follow.
Privacy Policy (Privacy) - Publish a privacy policy outlining how privacy is considered as part of platform operations.
Deprecation Policy (Deprecation) - Establish what the deprecation policy is for all APIs and services, identify what the process is for communicating and deprecating services--settings expectations for how things will change.
Service Accord / SLA (Reliability) - Consider what service level agreement we can offer. If nothing else at least publish a service accord setting the tone for the engagement, and what level of service we honestly intend to offer.
User management API (Management) - Publish an API providing programmatic access to the user management system.
Account management API (Management) - Publish an API providing programmatic access to the account management system.
Application management API (Management) - Publish an API providing programmatic access to the user management system.
Plan management API (Management) - Publish an API providing programmatic access to the plan management system.
Usage management API (Management) - Publish an API providing programmatic access to the usage management system.
Billing management API (Management) - Publish an API providing programmatic access to the billing management system.
Service management API (Management) - Publish an API providing programmatic access to the service management system.
Message management API (Management) - Publish an API providing programmatic access to the message management system.
Mocks (Virtualization) - Let's consider providing mock versions of the APIs, even if it is just using a 3rd party service, generated with the OpenAPI.
Sandbox (Virtualization) - Let's also consider providing an entire sandbox edition of the APIs available at a separate URL, allowing developers to play with the API without production concern.
Containers (Deployment) - Let's look into providing containerized edition of all or some of the APIs, allowing them to be deployed in any cloud infrastructure.
Image (Deployment) - Let's also consider providing Amazon AMI, or other virtualized images of some, or all of the APIs, allowing the compute to be offloaded to a consumer's account, and run APIs in their environment.
Blog (Communications) - Let's setup a new blog for the platform. Let's set up as part of the developer portal using Jekyll, or even set it up as its own repository.
Blog Feed (Communications) - Set Up an Atom feed along with the blog, allowing feeds to be syndicated.
Twitter (Communications) - Setup a Twitter account for the API program.
Communication strategy (Communications) - Establish a communication strategy for publishing blog posts, Tweeting, and pushing content to other channels.
Support strategy (Support) - Let's establish a support strategy. Establishing which channels we are using and how they are maintained, feeding back into the road map, issues, and change log.
Evangelism strategy (Evangelism) - We need to also establish an evangelism and outreach strategy, detailing how we will be reaching out to developers, telling stories, engaging in conversations, and attending events.
API monitoring (Monitoring) - Choose a service for monitoring the APIs uptime, details of their request, and other items detailed in the SLA for the platform.
Communicate monitoring (Communications) - Pull together a strategy for communicating out how the platforms monitors, and how consumers can get more information, data, and notifications.
API performance (Performance) - Pull together a strategy for testing for and monitoring of performance, setting benchmarks and regularly evaluating if they are being met.
Communicate performance (Communications) - Pull together a strategy for communicating out how the platforms approaches performance of the platform., and how consumers can get more information, data, and notifications.
Status dashboard (Monitoring) - Set Up a status dashboard with an external service, sharing real-time, and historical data about the platform availability and reliability.
Communicate status (Communications) - Pull together a strategy for communicating the presence of a status dashboard, and how consumers can use it to stay in tune.
API security (Security) - Scan the API domain, and all available paths using security software. Establish a regular schedule and approach to dealing with security, and execute religiously.
Security page (Portal) - Publish a page dedicated to security in the developer portal sharing how the platform approaches security, and any updates regarding concerns, vulnerabilities, and other relevant information.
Communicate security (Communications) - Pull together a strategy for communicating with consumers about how security is handled. Even come up with a strategy for how communication will be handled during potential security incidents--so that we are prepared.
API licensing (Licensing) - Let's pull together licensing for the API. Ideally we wouldn't have to do this, but in the United States APIs currently can have copyright applied, so it's good to choose a creative commons license and apply to all APIs--encouraging reuse and integration.
Schema licensing (Licensing) - Let's also think about how the schema used across API requests and response be licensed, applying a creative commons or other liberal licensing.
Data licensing (Licensing) - Let's also consider how data will be licensed, allowing for a variety of open and proprietary approaches to exist.
Code licensing (Licensing) - Publish any of the SDKs, code samples, and other code developed for the platform to Github with an open license applied, ensuring that consumers can integrate into their businesses without concern.
Communicate licensing (Communications) - Pull together a strategy for communicating out the licensing for the platform.
Branding (Branding) - Let's put thought into a basic branding strategy, which logos, and other assets can be provided to API consumers to use in their applications.
Branding page (Potal) - Publish a page in the developer portal where the branding strategy and assets can be published providing guidance for developers when it comes to properly representing the platform.
Discovery (Discovery) - We need to consider how we want the APIs to be found. Will it be public, or secured for private and partner access. Aggregating thoughts and strategies for making sure the APIs get found.
APIs.json (Discovery) - Craft an APIs.json file for the project and publish it in the root of the developer portal
Postman collection (Discovery) - Craft a Postman Collection for the project and publish it in the root of the developer portal
Webhooks (Webhooks) - Let's evaluate how Webhooks can benefit platform operation, allowing consumers receive URL / URI pushes when specific events occur. We need to pull together an events strategy, and pull together plan for how webhooks operate.
Webhook page (Portal) - Publish a page in the developer portal with all information about webhooks, how they work, which events are available, providing as much information for consumers when they are integrating.
Webhook API (Management) - Publish a webhooks API allowing programmatic control over the webhook workflows.
Announce Webhook API (Communications) - Pull together strategy for communicating out the webhooks portion of the platform.
Integrations (Integration) - Let's make sure we have an approach to showcasing the integration possibilities with the platform, either directly baked into the APIs, or externally through connectors and other types of integration.
Integration Page (Portal) - Publish a page to the portal dedicated to showcasing integrations, and helping consumers understand what is possible.
Integration API (Integration) - Publish an API for programmatically accessing the integrations that are available via the platform.
Announce Integration API (Communications) - Pull together a strategy for communicating out the integrations available, and how consumers can take advantage of them. Maybe also consider having a link so other platforms can contact and maybe get their platform integrated.
Developer Page (Evangelism) - Publish a page on the site showcasing developers. Allow platform users to opt in for publishing their profile to the developer showcase page, and maintain their title, description, logo, and links.
Developer API (Evangelism) - Publish an API for programmatically accessing the developer profiles that have been published to the showcase page.
Communicate Developer (Evangelism) - Pull together a strategy for communicating out the developer showcase, and how developers can get involved.
Applications Page (Evangelism) - Publish a page for showcasing the applications that have opted in to be shared publicly.
Communicate Applications (Evangelism) - Pull together a strategy for how we will be communicating out the application showcase.
Storage API (Deployment) - Deploy an API that provides access to all the storage for the system, which will be used across other APIs, and eventually contain other 3rd party services--added to the road map.

When something on the road map has been satisfied, or an issue has been resolved we try to move it here. Since this is just a prototype API project, once something on the road map gets reflected on the main page for the site, or shared as a story on the blog, we'll mark it done, considering it part of the operations.