A consulting project we’ve engaged in recently involves publishing a new API from the Patent Examination Data System (PEDS) out of the US Patent Office (USPTO). The USPTO provides a full JSON or XML download of data regarding the examination of patents, as well as an API, published using an ElasticSearch index. The resulting API doesn’t meet the demands of our client, so we’ve been working to help them publish a better designed version of the API that will better meet their needs. Version 1.0 of the API will be all about taking the existing data set and making it easier to work with via a more intuitive interface, but the roadmap will involve an event-driven API layer on top of the patent review process.
The first versions of an API are always about getting a handle on the resources being made available, but for Streamdata.io, the future versions will almost always involve the investment of event-driven architecture, making the core resources more response, proactive, and real time. Improving upon the initial resource, going beyond its request and response origins, where developers have to ask for what they want, and allowing them to subscribe to topics and receive pushes of data via webhooks, or establish persistent API connections and receive complete or incremental updates when any event has occurred.
We are still mapping out what the event-driven layer will look like on the patent examination process, but understanding when there are new patents or changes to any existing patent are the obvious candidates for subscriptions. We envision the ability to receive webhook push notifications for any company and their patent portfolio, as well as when there are changes to any existing patent. Allowing for easy monitoring of companies patent portfolio, and the finer details of the patent examination and evolution process. We have other ideas in mind, but we want to get up and running with the core API, develop a handful of applications on top of the API before we talk more about what is possible.
It is always interesting to think about the event-driven opportunities on top of an existing API platform. Especially when the resource is something that is always changing and evolving, and involves so many corporate, government, and individual actors. The challenge for us is always ensuring there is a simple, yet robust, and performant web API available first. This is why we end up consulting with so many firms to help ensure there is a solid API base, this way we can quickly get to work on the fun part, delivering the event-driven layer on top. Turning any valuable API resource into a more response, event-driven solution, pushing valuable data to those who need it, whenever something important occurs.