The third API Specifications Conference (ASC) will take place on September 28th and 29th. This year as part of the call for proposals we’re going to be accepting and announcing five talks early. In order to have your talk considered, you need to have your submission in by May 28th, 11:59pm PDT. 

The early bird submission will give you advance notice to prepare for your talk and your talk will be announced before the full schedule is announced. 

Submit your talk at: https://sessionize.com/api-specifications-conference-2021/

Early bird deadline: May 28th, 11:59pm PDT

Regular deadline: June 11, 11:59pm PDT

We will notify any speakers who have an early bird submission accepted within two weeks after the deadline. 

If you need help or advice for your submissions, please contact speakers@openapis.org. If you are a first-time and/or underrepresented speaker, we especially want to help you submit a talk and are available to help you work through talk ideas or how to structure your proposal. 

On behalf of the organizing committee,

Taylor Barnett, Program Chair, ASC 2021

After a successful virtual event last year, we are back again this fall. Mark your calendar for the return of the API Specifications Conference (ASC), this year as an all-digital event on September 28th and 29th, 9:00 am – 3:00 pm PDT. 

ASC 2021 will include keynotes, sessions, and open discussions on specifications and standards behind the cutting-edge technologies that chart the future of APIs. And we want to hear your talk proposals!

We are looking for talks that range from beginner introductions to API specifications through best practices and forward-looking sessions on API specifications and standards, including OpenAPI Specification, gRPC, AsyncAPI, GraphQL, RAML, API Blueprint, oDATA, JSON Schema, and others. We want to hear your talks on how you are using specifications and standards in practice. Topics can include but are not limited to design, testing, security, lifecycle, runtime, governance, and developer experience. In-depth talks and discussions will enable attendees to get familiar with these specifications and standards and how to use them to deliver better API experiences. 

Check out last year’s talks to get an idea of the different kinds of talks we have had in the past: https://www.youtube.com/playlist?list=PLcx_iGeB-Nxil4S7-0Y1Y5r0oLahy3f0Y

The Call for Talks is open: 

* Submit your talk: https://sessionize.com/api-specifications-conference-2021/

* Submissions Deadline: June 11, 11:59pm PDT

If you need help or advice for your submissions, please contact speakers@openapis.org. If you are a first-time and/or underrepresented speaker, we especially want to help you submit a talk and are available to help you work through talk ideas or how to structure your proposal. 

We’re looking forward to your proposals and participation that will make ASC 2021 a great event again this year!

On behalf of the organizing committee,

Taylor Barnett, Program Chair, ASC 2021

This post is authored by Dr. Pedro J. Molina, Founder at Metadev & Member at ISA Group, University of Seville.

The Special Interest Group on SLAs inside OpenAPI is working to create an extension to define Service Level Agreements for API.

The latest work of the group was recently presented to the OpenAPI Technical Steering Committee for feedback and to ensure alignment with general policies.

The SLA4OAI working group needs your help to begin realizing these benefits in practice as an extension to the OpenAPI Specification. This post will explain what an SLA is, why it matters, and how new tooling can help solve important problems faced by all API providers today.

What is an SLA?

SLA is short for Service-Level Agreement, and it defines a set of metrics and constraints regarding service availability, quality of the service like minimal and maximal throughput, latency, quotas, rate-limits, etc.

Such constraints are applied to specific endpoints or operations (resources) inside an API.

These constraints can optionally be grouped in several plans and can have price.

The problem to solve

The API industry adopted OpenAPI to move from an informal to a formal definition of APIs that can be consumed by humans for documentation and machines for automation. 

In the same way, commercial APIs often have an SLA described in informal language published over HTML pages or PDF docs, hardly usable by machines.

Therefore, a need for a standard to help to describe SLAs is pretty clear.

Use Cases with APIs

Having a standard format to describe SLAs for APIs will enable the following Use Case scenarios, to cite a few:

1. SLA Documentation: to describe the limits, rates, quotas and expected availability, and how they apply to different endpoints.
2. Description of Plans and prices: explaining different usage plans and costs.
3. Feature and Cost comparison based on (2): allowing the comparison of alternative APIs based on availability and quality features.
4. SLA Testing tools: to check if a given limit is applied by the API as documented.
5. SLA Measure: to check the metrics are inline with the SLA contract declared.
6. SLA Enforcing: to implement quotas and limits as a middleware for an API.
7. SLA compliance tracking (globally or per user): to measure the degree of real compliance of an API with the SLA respect to the theoretical one.
8. Automatic calculation of combined SLA for composed services. Several API can be used together to create complex services. SLA properties for the composition can be derived from the expected SLA from the simple components.
9. Easy setup of SLAs in API Middleware tools. Some Middleware tools provide features to implement SLA concepts like metrics,  limits, quotas, rate limits, etc. Having a standard & formal way to define it will simplify the initial configuration of such features.

Current Specification

After months of work the Special Interest Group (SIG) generated the consensus to create a minimal version 1.0 for people to start using and for providing feedback.

You can take a look at the complete SLA specification.

Early feedback, roadmap, and open issues

SLAs definitions have an entity per se to be described in an stand-alone document apart from your OpenAPI definitions. For example, APIs described with AsyncAPI may also benefit from SLA descriptions.

Some open design questions where we would appreciate community feedback include:

1. What is the best way of representing SLA information? There is an open discussion about if we should extend the OpenAPI document directly or if we maintain the document apart and then use references to API operations. This can be achieved using different techniques like embedded extension, patch/merge mechanisms, overlays. All of them provide pros & cons. Therefore, we are evaluating trade-offs here.
2. SLA definitions need to reference endpoints. REST endpoints contain a URL plus a HTTP Verb (or alternatively, can be referenced by an OperationId). AsyncAPI operations will differ for sure. A reference mechanism needs to be chosen to allow pointers to specific API operations at OpenAPI, AsyncAPI or others.
3. Usually constraints and policies apply to a set of endpoints. Instead of enumerating all of the endpoints one by one, a mechanism based on globbing (*), or Regular expressions would be very useful to briefly describe all the endpoints affected by a given limit. OpenAPI tags were also suggested as a way to apply the limits.

Call for Implementers

Time for action has arrived!

Implementers can start building new exciting tools targeting today problems that can put in practice the usage of the extension to show its usefulness. Inside the SIG we will start also doing so very soon just to show a couple of examples of use. 

So if you are interested, please feel free to ask for details and reach out to the SIG about your plans to implement it. We plan to maintain a list of related tools using the SLA spec.

To know more

1. Current SLA4OAI Spec
2. Wiki and working drafts
3. SLA-SIG Mail List
4. SLA4AOI Presentation at TSC: slides & YouTube video
5. Paper: The Role of Limitations and SLAs in the API Industry (ESEC/FSE ’19)

Acknowledge

Thanks to all the members taking part of the SLA SIG: Tim Burks (Google), Dave O’Neil (Apimetrics), Paul Cray (Apimetrics), Hyungjun Lim (Google), Khushan Adatiya (Google), Fran Mendez (AsyncAPI), Emmanuel Paraskakis (Independent), Phil Sturgeon (Stoplight), Nikhil Kolekar (Independent), Prithpal Bhogill (Google), Madhurranjan Mohaan (Google), Isaac Hepworth (ex-Google), Scott Ganyo (Google), Kin Lane (API Evangelist), Mike Ralphson (Independent), Jeffrey ErnstFriedman (OpenTravel Alliance), Antonio Ruiz-Cortes (ISA Group/University of Sevilla), Pedro J. Molina (Metadev & ISA Group) and Pablo Fernandez (ISA Group/University of Sevilla).

Thanks also to the TSC and OpenAPI Initiative members for encouraging us and providing the resources and feedback to make this possible.

Coming Soon to An API Near You – OpenAPI Specification (OAS) 3.1.0!

Do you remember the old days when seeing a trailer to an upcoming movie filled you with excitement and anticipation? Well, theaters may still be closed, but there’s no need to lose your excitement for a new release, especially one that’s three years in the making.  We suspect many of you have been sitting, fingers poised above keyboards, waiting anxiously for the release of OpenAPI 3.1.0.   

Well, the wait is over! News is starting to emerge on the new features and we’re curious which parts of OpenAPI 3.1.0 you are looking forward to the most.  Is it the JSON Schema compatibility, the new webhooks support, the improved reusability…?

How do I get a Free Pass to Confoo?

It’s simple! Send us your favorite features and briefly tell us how you plan to use it.  We will enter you in a drawing for a free pass to Confoo 2021 taking place, February 24-26th. 

To enter, tweet your suggestion with @openapispec #oas31confoo by Monday, February 22, 5 pm Eastern. The winner will be selected by a random number generator.

The conference is coming up quick (and so is the release of OpenAPI 3.1.0).  Send us your feedback. 

The OpenAPI Specification relies on developers just like you to keep it current and relevant.  Join us and make your mark on the future of API standards. New to OpenAPI? Sign up for our newsletter!

The OpenAPI Initiative held its 2nd annual API Specifications Conference (ASC) online, September 9 – 10, 2020. A reimagined version of the famous APIStrat Conference, ASC continues to evolve and become a must-attend destination for folks interested in API specifications of all sorts. OpenAPI Specifications, RAML, Blueprint, gRPC, OData, JSON Schema, GraphQL, AsyncAPI, and other formats were all topics, enabling attendees to get familiar with these formats and discuss how to use them in practice.

ASC achieved a 91% attendance rate out of 373 unique registrations. We had 318 attendees, 42 speakers; 6 sponsors; and 7 staff. Feedback from attendees was overwhelmingly positive with 100% of survey respondents rating the overall experience as “Good”, “Great”, or “Excellent”. 88% said the content quality was “Great” or “Excellent.” Presentations included Github describing their journey towards adopting OpenAPI , OAuth2.1 and other updates in securing your API, and a unified API design methodology , among other engaging topics.

OpenAPI only charged $39 per person for the event and provided 18 community scholarships. We raised $2,500 for Code2040 and are proud to support their efforts.

While we missed seeing everyone in person, one benefit of an online event is that we could record all the sessions. We posted them on the OpenAPI Initiative Youtube channel. Also, many presenters uploaded their slide decks to Sched. We’ve made a brief tutorial to find sessions with slides easily. 

Stay tuned to learn more about ASC 2021 when information becomes available. Sign up for our Newsletter!

APIs are essential in many scenarios today but are still just interfaces at the end of the day. So what gives an API meaning? How does an API remain usable and useful? Learn how to look past the interface for a deeper perspective on API products at OpenAPI’s ASC 2020.

The API Specifications Conference (ASC) is a place for API practitioners to come together and discuss the evolution of API technology. The ASC includes cutting edge technology keynotes and sessions that chart the future of APIs with in-depth specification and standards discussions. The event is designed to be highly interactive, with plenty of discussion time throughout the sessions.

Keynote Panel: What’s the Specification for API Products?

Moderated by Erik Wilde (Axway), join keynote speakers Mike Amundsen (Amundsen.com, Inc.), Yina Arenas (Microsoft), Adam DuVander (EveryDeveloper), and Gail Frederick (Salesforce) on Thursday, Sept 10 at 9 AM PST as they discuss specification for API products. Learn how knowing why we are building these APIs should help us do a better job of identifying valuable specifications and delivering maximum value to customers.

Register Here

Keynote Moderator + Speakers

Erik Wilde supports companies on their digital journeys by helping them with their strategy and programs. Based on his background in computer science his focus is on technology. With his extensive experience when it comes to API initiatives within companies, however, he also focuses on business and organizational issues. Erik is a frequent speaker at conferences worldwide, publishes regularly in a variety of places, and is active in standardization efforts.

Adam DuVander is a developer communicator and cheerleader. He helps companies reach and engage with developers

through authentic content. Previously he worked for some of the best API and developer companies, including Zapier and SendGrid. Many still find his writing at ProgrammableWeb, where he served as the first editor of the influential journal. He’s a published author and international speaker, but his kids still aren’t impressed.

Yina Arenas leads engineering for Microsoft Graph, the gateway to data and intelligence in Microsoft 365 and one of the highest-profile engineering projects at Microsoft. During her career at Microsoft, she has been building the platform that enables developers to build applications that access data and relationships across Office and all Microsoft cloud services. She is from Bogota, Colombia and joined Microsoft in 2010 after graduating with a Master’s degree in Computer Engineering from the University of Virginia. She lives in Seattle with her husband and 4 energetic sons and actively participates in activities that grow, retain and empower women in technology. Find her on Twitter: @yina_arenas.

An internationally known author and speaker, Mike Amundsen consults with organizations around the world on network architecture, Web development, and the intersection of technology & society. He works with companies large and small to help them capitalize on the opportunities provided by APIs, Microservices, and Digital Transformation.

Amundsen has authored numerous books and papers. He contributed to the O’Reilly book, “Continuous API Management” (2018). His “RESTful Web Clients”, was published by O’Reilly in February 2017 and he co-authored “Microservice Architecture” (June 2016). His latest book — “Design and Build Great APIs” — for Pragmatic Publishing is scheduled for release in July 2020.

Gail Fredrick is the SVP Engineering, Salesforce Developer Experience at Salesforce.

Roles prior to Salesforce include VP Mobile and Developer Ecosystem at eBay,  engineering director at Intel’s Open Source Technology Center, the heart of Linux at Intel. Nerd-vana. And before that, mobile software architect at Medio Systems in Seattle, WA. Medio was acquired by Nokia/HERE in July 2014. Her treatise on standards-based mobile web development is “Beginning Smartphone Web Development”, published by Apress in December 2009.

The 2020 speakers have been announced, and their talks cover the spectrum of expert technologists, business professionals, open source contributors, and more! Learn from companies and organizations like GitHub, Google, Microsoft, MuleSoft, OpenTravel Alliance, Postman, SmartBear, TravelPort, Vonage, and others. Some highlights include:

Dealing with legacy systems? Go through “From 0 to OpenAPI: Describing a 10-year old API with OpenAPI @ GitHub” by Marc-André Giroux and Andrew Hoglund, GitHub

Want to learn about timing pandemic-helping techniques? Take in “All the Interoperability, But None of the Contact” by Jeff ErnstFriedman, OpenTravel Alliance

Sneakily fascinated for the inside scoop of how Postman dogfoods their own tech? Attend “How Postman uses Postman to Build APIs” by Joyce Lin, Postman 

Curious about how to implement a unified API design process that goes beyond adopting a single API style or specification? You definitely want to check out “GraphQL, gRPC and REST, Oh My!: A Method for Unified API Design”  by Mike Amundsen, amundsen.com Inc.

Hungering to inject delight into the developer experience? Perhaps “Create Delightful SDKs from OpenAPI” by Lorna Mitchell, Vonage, is your cup of tea.

Increase your skills, meet your peers, get a look into the latest research and latest real-world case studies. ASC 2020 is a virtual conference this year, being held Sept 9-10. 

Check out the full schedule now! https://asc2020.sched.com/

Register today! https://events.linuxfoundation.org/openapi-asc/register/

ASC why!

Do you know why you should come to the API Specifications Conference in Vancouver this October? It’s okay if you are not sure, just ASC!

Many of the challenges we face as developers are related to that interface between the API provider and the API consumer. Using some kind of contract has become the norm, but developing and managing those contracts presents its own unique set of problems and opportunities to explore.

ASC is dedicated to bringing the community together to present and discuss solutions focused on the entire lifecycle of the interface aspect of APIs. We chose the conference name explicitly to convey that this event is not focused exclusively on using OpenAPI descriptions.

The OpenAPI Initiative has never seen OpenAPI as a one-size-fits-all solution. That’s why ASC welcomes participation and content from the communities working on AsyncAPI, gRPC, GraphQL, OData, JSON Schema etc. as well as HTTP APIs. So if you want to learn the broad range of possible solutions, which might be the best fit for the problems your organization faces, just ASC!

Don’t take our word for it? Read about OpenAPI and ASC from thought leaders in the API ecosystem.

Kin Lane – http://apievangelist.com/2019/09/17/i-will-be-at-the-api-specifications-conference-in-vancouver-next-month/

Gareth Jones – https://dzone.com/articles/apis-and-breaking-change-how-implementing-apis-for

• Kin Lane

To learn more, please see: https://events.linuxfoundation.org/events/asc-2019/