Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Machine-Readable Definitions for All Things API, Including Your Bots

DZone's Guide to

Machine-Readable Definitions for All Things API, Including Your Bots

Machine-readable APIs are even more important for bots that utilize artificial intelligence and machine learning to provide interoperability.

· AI Zone
Free Resource

Bring the power of Artificial Intelligence to IT Operations. Brought to you in partnership with BMC.

Every aspect of my business runs as either YAML or JSON. My blog posts are YAML stored on GitHub, viewed as HTML using Jekyll. All the companies, services, tooling, building blocks, patents, and other components of my research all live as YAML on GitHub. Any API I design is born and lives as an OpenAPI YAML document on GitHub. Sure, much of this will be imported, exported, and exported with a variety of other tools, but the YAML and JSON definition is key to every stop along the life cycle of my business and the work that I do.

It isn’t just me. I’m seeing a big shift in how many platforms, services, and tooling operate, often times with YAML, and still, in many situations, with JSON, XML, and CSV at the core. Everything you do should have some sort of schema definition, providing you with a template that you can reuse, share, collaborate, and communicate around. Platforms should allow for the creation of these template schema and enable the export and import of them, opening up interoperability and cross-platform functionality — much like APIs do in real-time using HTTP. This is what OpenAPI has done for the API lifecycle, and there should be many complementary or even competing formats that accomplish the same for specific industries and use cases.

You can see this in action over at AWS, with the ability to export your Lex bot schema for use in your Alexa skill. Sure, this is interoperability on the same platform, but it does provide one example of how YAML and JSON definitions can help users share, reuse, and develop common templates for not just APIs but also the clients, tooling, and other platforms we are engaging with. You’ll see this expand to every aspect of tech as continuous integration and deployment takes root, and GitHub continues its expansion beyond startups, into the enterprise, government, and other institutions. Along the way, there will be a lot of no-name schema finding success, but we will also need a lot more standardization and maturing as we’ve seen with OpenAPI for all of this to work.

I hear a lot of grumbling from folks when it comes to YAML. I get it. I had the same feeling. It also reminds me of how I felt about JSON when it first emerged. However, I find YAML to be very liberating of brackets, slashes, and other delimiters, but I also find it is just one format, and I should always be supporting JSON, XML, and CSV when it comes to one-dimensional schemas. I don’t find it a challenge to convert between the formats or keep some things one-dimensional to bridge to my spreadsheet-oriented users. I actually feel it helps me think outside of my bubble. I enjoy rifling through the YAML and JSON templates I find on GitHub from a variety of operations, defining their bots, conversational interfaces, visualizations, CI/CD, configuration, clients, and other aspects of operations. Even if I’m never using them, I find it interesting to learn how others define what they are up to.

TrueSight is an AIOps platform, powered by machine learning and analytics, that elevates IT operations to address multi-cloud complexity and the speed of digital transformation.

Topics:
ai ,machine learning ,bots ,api

Published at DZone with permission of Kin Lane, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}