openapi-python-client
| yaml-reference-parser | openapi-python-client | |
|---|---|---|
| 1 | 8 | |
| 40 | 1,403 | |
| - | 2.9% | |
| 0.0 | 9.0 | |
| over 1 year ago | 9 days ago | |
| CoffeeScript | Python | |
| - | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
yaml-reference-parser
-
YAML: It's Time to Move On
> There's no canonical YAML implementation
The formal grammar counts as canonical and several implementations are derived from it: https://github.com/yaml/yaml-reference-parser
openapi-python-client
-
After 3 Years, I Failed. Here's All My Startup's Code
There's a huge number of them https://openapi.tools/#sdk
Including the semi official tools https://github.com/OpenAPITools/openapi-generator
Now if you want multi language generation and especially high quality you may have to spend a lot of time evaluating different choices. I decided that the official java client didn't generate very nice python code and went with https://github.com/openapi-generators/openapi-python-client even though it's a small personal project with a primary developer+random contributions from users. It just seemed nicer to use for python. Finding which generator to use especially for JavaScript seems difficult
-
What makes a good REST API?
openapi-python-client: Generate API client for Python
-
GraphQL is for Backend Engineers
On the backend, developers either need to manually document the entire API or rely on auto-generation tools that don’t fully meet their needs. Consumers face the same choice, write code by hand or workaround the bugs in their SDK generator (stated, lovingly, as the maintainer of an OpenAPI client generator). On top of this, these solutions result in inconsistent understandings of the API. Reproducing errors becomes time-consuming and frustrating, which feels like a battle instead of a collaboration. What we need is a shared language to describe how the API works—one that doesn’t add unnecessary layers of abstraction or manual work.
-
Microsoft Kiota: CLI for generating an API client to call OpenAPI-described API
Has anyone tried Kiota, specifically the Python support? How does it compare to https://github.com/openapi-generators/openapi-python-client ?
-
Python toolkits
I think we use these - https://github.com/openapi-generators/openapi-python-client
- YAML: It's Time to Move On
-
Replacing FastAPI with Rust: Part 2 - Research
Tallying up the results, we get 7/8 "MUST" requirements met. I think that Paperclip + actix-web seems like the most promising candidate. I'm really not opposed to writing the OpenAPI v3 construction myself as I've worked with the structure a fair bit in my openapi-python-client project (shameless plug).
-
Replacing FastAPI with Rust: Part 1 - Intro
Automatic documentation via OpenAPI, which lets you do things like generate Python code that knows how to talk to your API.
What are some alternatives?
starlark - Starlark Language
sqlx - 🧰 The Rust SQL Toolkit. An async, pure Rust SQL crate featuring compile-time checked queries without a DSL. Supports PostgreSQL, MySQL, and SQLite.
ron - Rusty Object Notation
nestedtext - Human readable and writable data interchange format
paperclip - WIP OpenAPI tooling for Rust. [Moved to: https://github.com/paperclip-rs/paperclip]
typescript-json-schema - Generate json-schema from your Typescript sources
okapi - OpenAPI (AKA Swagger) document generation for Rust projects
jq - Command-line JSON processor [Moved to: https://github.com/jqlang/jq]
warp - A super-easy, composable, web server framework for warp speeds.
cue - CUE has moved to https://github.com/cue-lang/cue
rweb - Yet another web server framework for rust