Welcome to moonwalk Discussions!

[earth2marsh]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[arno-di-loreto]

Hello everyone!
First and foremost 👏👏👏👏 to all people involved, the direction taken for v4 looks really nice!

I'm Arnaud (also known as apihandyman), I'm currently working on OpenAPI, API design, and API Governance at Postman. I've been reading/writing/generating/processing OpenAPI since v2 and took advantage of it to design, document, and review APIs (reviewed thousands of them 😱). I also talked and wrote a lot about it.

I hope that bringing my OpenAPI user and API design reviewer perspectives will help create an even more user-and-machine-friendly, consistent, and evolvable format.
Side note, I'm currently working on a refresh of my OpenAPI map to fix some missing elements and add v3.1 support (which should be available this month) and after that why not add v4 during its inception.

[karelhusa]

Hi everyone,
I am Karel and have been working with APIs for almost 20 years, doing integrations in large organizations, API consulting, and organizing API-related training. I appreciate the effort on v4, and existing proposals seem promising!

I would like OpenAPI to become friendlier to business users, i.e., end-users of the information provided by APIs. A lot is spoken about developer experience, but I believe this needs to shift towards end-user (of the information) experience, which will also improve developer experience.
OpenAPI 3.0 has been pretty intertwined with HTTP protocol; current v4 proposal ideas seem to get closer to the business (e.g., HTTP verbs moving to a lower level). And, the role of developers in APIs will IMHO decrease in the near future.

I would like to see more support for reusability, e.g., introducing more standard data types as libraries (e.g. percentage, email, UUID, IBAN, amount with currency, error message, etc.) People would decide whether to benefit from the standard types or define their own. A lot of integration effort is still spent on defining the same many times and transforming the same information between different structures and data types.

As an API trainer, I often look at OpenAPI from the learner's viewpoint and welcome every reduction of unnecessary complexity. Currently, it's impossible to understand an API without knowledge of HTTP.

I would also like a replacement for the PetStore sample API; for different design flaws (e.g.,/pet/findPetsByStatus?status=available instead of usual /pets?status=available) and also don't like the idea of pets sitting at the store and waiting (treating them as things). Though it became a legendary API, I instead developed simple banking-like API for my courses (https://bankground.apimate.eu ).
As a trainer, I would appreciate an API that is easilly accessible by learners (something they usually do and know), and it's publicly available implementation (and Docker image), and really validates the data and contains meaningful business rules. Only then it's fun to play with.

[fariadev22]

Hello there 👋 ! My name is Faria Rehman, and I am a senior software engineer at APIMatic, where I have gained over six years of experience working with various API specification formats, including OpenAPI. I have had the privilege of leading the development of the API Transformer product, which has provided me with valuable exposure to a variety of formats and the challenges that arise during their conversion. Additionally, I play a critical role in ensuring a seamless experience for people looking to generate client libraries/SDKs and developer experience portals by bringing in API specification formats.

I also share my insights on API specifications through my blog, which you can find at https://medium.com/@fariarehman. As someone who is passionate about contributing to the industry and helping others, I look forward to engaging in discussions and sharing my experiences and knowledge :)

[rattrayalex]

Hey all,

I'm Alex, founder of Stainless, an API tooling company doing codegen and other things around OpenAPI. Previously, I was an engineer on the API team at Stripe, where I worked on API docs, client libraries, codegen, and the generation of the OpenAPI spec from our internal API framework.

I'm tremendously excited by what I see so far in the v4 proposal here. My top goal is making OpenAPI easier for developers to maintain. My secondary goal is making OpenAPI more natural for tooling like ours, and others in the ecosystem (ideas like resource orientation could remove a lot of things I've had to do on top of OpenAPI, for example).

I love seeing things get a little flatter, more concise, and expressive. I'm always game to be suckered into a meaningful bikeshed.

Thanks for putting this together!