We pay pretty close attention to the API-Craft meetup, a meetup group for ”people who design and build and test APIs,” organized by Emmanuel Paraskakis (@manp), with meetings and hackathons almost every month in San Francisco, CA. It’s been going on since 2013, and it’s been high quality all along. We blogged about one meeting, “Real Time APIs and Big Business APIs,” last year.
Topics for the meetups generally include: API Design, the API development process, future directions, business issues, and unabashed API evangelism.
Naturally, we attended the June monthly meeting, off 9th street in San Francisco. There were approximately 25 people listening to three different presenters while eating pizza and drinking beer. Questions were mostly technical, but sometimes covered business (“How does Capital One measure its investment in API development?”) and politics (“How does the Open API Initiative guard against undue corporate influence?”).
Vukovic talked about the “Future of API Management,” covering in detail some of the main strengths of the Oracle API Product for users. He emphasized how it is fully integrated with Apiary and used Postman to work through a smooth demo.
As he stated, if you’re an API vendor, you better use your API to do the demo, otherwise it’s just not real. Vukovic emphasized simplicity in focus and design, quoting Steve Jobs. He said “Focus on what you work on, are you the Sun or the Planet?”
Dave Goldberg – Director, API Products, Capital One (@davidgoldberg)
Goldberg talked at length about the challenges and opportunities of API tooling in a distributed enterprise environment. He stated emphatically that “Banks are changing,” and talked about even with Capital One’s early focus on monetizing APIs, it is still heavily experimental in nature with many on-going challenges. Capital One has built a full lifecycle tool internally that allows them to manage APIs. This is extremely useful for API tooling in a distributed enterprise environment.
They decided early on to bet on Swagger, and they are a part of the Open API Initiative.
I was impressed by Goldberg’s openness in stating that it was an evolving process with many challenges. I asked how API development is measured on the business side. He said they “won’t be the Twilio of banking tomorrow,” that it is just not realistic. Capital One is moving toward APIs that are revenue drivers for the company. But that understanding the scale of the company is important: Capital One is in the billions in sales, so small products on the level of even tens of millions in annual sales are virtually meaningless. The best way is to increase sales is to focus on improving current products by, say, 1% and you will make a real difference on the bottom line.“ We believe ultimately that the entire business becomes a platform.”
Ron Ratovsky – Swagger Developer Evangelist, SmartBear Software (@webron)
The Open API Initiative is currently working in the next version of the OpenAPI Specification formerly known as Swagger. Ratovsky was introduced as “the soul of the Swagger specification”, and he covered upcoming features in OpenAPI 3.0.
When is OpenAPI 3.0 coming out? They were aiming for mid-summer (end of July) but Ratovsky said that will not happen since there were so many feature requests.
They are reworking Parameters:
Schema, Cookie Parameters, Parameter Deprecation, Examples, Body Parameters (won’t be a parameter type)
And Considerations: Must be… Pragmatic, Consistent, DRY, Flexible… It just works, it’s not going to break.
Structure is changing since currently there are too many definitions at the top of the spec: Reuse, Simplified Similar Responses, Changes to Host, Version Identifier
Upcoming topics include: Hypermedia Support, Full JSON Schema Support, RFC 6570/Path Tempting Support
And some possible Additional topics include: Unique Path Identification, Content Negotiation Support, Security Definitions, Additional Protocol Support
There was concern expressed about maintaining neutrality. “How can you protect the spec from the major corporations?”
He responded: “We are individuals who are working on the spec. No one is from Google, for example, even though they’re a member. Google is invested in pushing the spec as a standard. They were a part of the voting for the TOC, like everyone else is. But ultimately, we won’t make everyone happy.”
Finally, Ratovsky asked anyone interested to please come in and give comments and request features. Since the Open API Initiative is a small team and they are dealing with “many many issues,” any help is appreciated. He said “It really is a community effort!”