swagger-editor VS OpenAPI-Specification

It has an online editor. You can easily play around with it and generate easy-to-use documentation.

After running the collection, I can see the API spec that was created and the mock server endpoint to test it. Looking at the rendered version on Swagger's OAS editor we can see pretty clearly this is a complete API that gets us exactly what we need.

While there’s not an officially supported Java SDK for Marqeta, building a Java client is quite straightforward, as the Core API is documented in both Swagger v2.0 and OpenAPI v3.0. The OpenAPI documentation is in beta, but it is generated directly from the API source code. To get a Java client, all we need to do is drop the OpenAPI yaml file into editor.swagger.io, modify the servers section to use the https://sandbox-api.marqeta.com/v3 as the URL, and tell it to generate a Java client.

Check out https://editor.swagger.io/ as a start point. In theory you should be able to generate a client for any swagger complient api and plug in your own auth and custom logic.

I would suggest using the swagger editor: https://editor.swagger.io/

Paste your json into https://editor.swagger.io and it will ask you if you want to convert it to yaml

Sure. You can use the editor from here for instance to define your endpoints and the data received and returned. By looking at the preloaded example you can figure out most of what you need to know about openapi. But if you need more info, the official documentation is pretty good.

Optional: If you make any changes to the plugin instructions or metadata models, you can also copy the contents of main.py into the main main.py file. This will allow you to access the openapi.json at http://0.0.0.0:8000/sub/openapi.json when you run the app locally. You can convert from JSON to YAML format with Swagger Editor. Alternatively, you can replace the openapi.yaml file with an openapi.json file.

I created another issue, this time quoting directly from swagger.io, showing screenshots from editor.swagger.io validation to prove that the library is creating invalid OpenAPI descriptions and that my suggestion creates valid ones, rephrasing the entire problem from a slightly different angle. I asked that if he decides to close the issue, to please not delete it so that it serves as documentation for others.

And I'll be using the OpenAPI Pet Store spec file as an example.

I saw your sibling comment about "keeping it simple," however that is a bit counter to "generates OpenAPI specifications" since those for sure are not limited to just application/json request/response bodies

I wanted to draw your attention to "normal" POST application/x-www-form-urlencoded <https://github.com/OAI/OpenAPI-Specification/blob/3.1.0/vers...> and its multipart/form-data friend <https://github.com/OAI/OpenAPI-Specification/blob/3.1.0/vers...>

The latter is likely problematic, but the former is in wide use still, including, strangely enough, the AWS API, although some of their newer services do have an application/json protocol

I know that's a lot of words, but the tl;dr would be that if you want your extension to be application/json only, then changing the description to say "OpenAPI specifications for application/json handshakes" would help the consumer be on the same page with your goals

Since FastAPI is based on OpenAPI, at this point you can also use the automatically generated docs. There are multiple options, and two are included by default. Try them out by accessing the following URLs:

This approach requires a constant context switch and is clearly not productive. Here, the OpenAPI Specification can help; you might already have it, but is it scalable? In this article, we’ll learn how to create an OpenAPI Specification document that is readable, scalable, and follows the principle of extension without modifying the existing document.

Phil Sturgeon, who along with Ben Hutton and Henry Andrews from the JSON Schema community, helped drive the push to full JSON Schema Draft 2020-12 compliance, has written a blog post for the official OpenAPIs.org website on how to transition your OAS documents from v3.0.x to v3.1.0.

In this article, we will be learning how to document API written in Node.js using a tool called Swagger. Swagger allows you to describe the structure of your APIs so that machines can read them. The ability of APIs to describe their own structure is the root of all awesomeness in Swagger. Why is it so great? Well, by reading our API’s structure, swagger can automatically build beautiful and interactive API documentation. It can also automatically generate client libraries for your API in many languages and explore other possibilities like automated testing. Swagger does this by asking our API to return a YAML or JSON that contains a detailed description of your entire API. This file is essentially a resource listing of our API which adheres to OpenAPI Specifications.

You may encounter APIs described as RESTful that do not meet these criteria. This is often the result of bottom-up coding, where top-down design should have been used. Another thing to watch out for is the absence of a schema. There are alternatives, but OpenAPI is a common choice with good tools support. If you don't have a schema, you can create one by building a Postman collection.

The principle behind the OpenAPI Specification (OAS – the industry’s most popular API specification format) is similar. It’s supposed to act as a blueprint for describing RESTful APIs.

OpenAPI 3.1 supports webhooks. It's not widely supported yet by implementations, but it's definitely there. https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.1/webhook-example.yaml

The Fastly API is huge. We have lots of customers who want to interact with it using their chosen programming language but our small set of manually maintained clients was not sufficient to handle the job of our ever-evolving API. We needed a way to scale up our API client support, and OpenAPI was the answer.