What may be interesting is #AsyncAPI which is like #OpenAPI but then oriented towards event-driven architectures. More appropriate for message passing protocols like #ActivityPub.

What may be interesting is #AsyncAPI which is like #OpenAPI but then oriented towards event-driven architectures. More appropriate for message passing protocols like #ActivityPub.
What would you use, when you need to generate API client based on OpenAPI Spec?
I've been using openapi-generator-cli for generating typescript APIs, and it's sort of okay, but I cannot say I'm completely happy with it.
Looking at https://openapi.tools/ I found https://www.stainless.com/ and apparently OpenAI is using this to generate their API client. Which is pretty good indicator.
Any recommendations?
Hey #fediverse, does anyone know which hosting companies are still implementing #Apache #CloudStack and/or #libcloud? I thought #Exoscale were, but it seems they have moved to a custom #OpenAPI based thing they made themselves. It's pretty good, but I was hoping to implement a standard... Wondering if it's worth exploring CloudStack further or it's a dead duck...?
Revolutionizing API Development: TypeSpec and OpenAPI Integration
In the rapidly evolving landscape of software development, the integration of TypeSpec with OpenAPI is transforming how developers approach API design. This innovative schema-first methodology not onl...
https://news.lavx.hu/article/revolutionizing-api-development-typespec-and-openapi-integration
I've been lax at updates to the dweb REST API which now supports most #Autonomi data types.
Web apps can POST/GET immutable data such as files and Archives (public and private), do multipart uploads of file(s), POST/PUT/GET Pointers (mutable references to other types) and POST/PUT/GET Scratchpads which are mutable storage for encrypted or public data.
To view #dweb #REST APIs:
- get rust
- cargo install dweb-cli
- dweb serve
In another terminal:
- dweb openapi-docs
Implementing Zalando RESTful API Guidelines with Quarkus https://myfear.substack.com/p/implementing-zalando-restful-api
#Java #Quarkus #OpenAPI #Zalando
Join me at DevFest Pisa 2025 where I’ll be sharing insights on how to elevate API experiences!
My talk, “Overlay and Arazzo: From API Definitions to API Experiences” will explore how we can transform APIs into seamless user experiences.
When: April 12, 2025
Time: 11:40 AM
Where: MACC - Pisa - Italy
Schedule: https://devfest.gdgpisa.it/talk/overlay-and-arazzo-from-api-definitions-to-api-experiences/
Hope to see you there!
Spec-First or Code-First? Choosing Your OpenAPI Strategy with Quarkus vs. Spring https://myfear.substack.com/p/spec-first-or-code-first-choosing
#Java #Quarkus #APIDesign #OpenAPI
Good progress on the #dweb REST APIs and improvements to the #OpenAPI docs today, all with the help of #actix and #utoipa
BTW #SwaggerUI is really cool
A few days ago I knew nothing about these but now I have a working API that is documented and can be tested live while reading those docs.
Someone asked if I might support #GraphQL but I haven't looked into that. Convince me that I should!
"The accompanying diagram is intended to help you quickly decide how to document an API, but particularly a REST API. The first split is just to make sure you are looking for the right kind of API.
Here is some more context to help you decide on an approach and get started."
https://gist.github.com/briandominick/3ffab6be460fbde799aa34e0a42a4299
Today I added #OpenAPI documentation to #dweb for building #RESTful #p2p web apps using your favourite web framework, or no framework at all.
All I have to do now is add more APIs!
But tbh, that's easy. The hardest part is actually the documentation.
So to make it more fun I'm adding the APIs need to enhance my #Fileman #Svelte demo.
So next is image preview which means adding /dweb-0/file-get
Having played a bit I'm now adding #OpenAPI docs with #Swagger UI to #Autonomi dweb using #utoipa and #utoipauto.
EDIT: switched from #utoipauto to #utoipa_actix_web
I'm neither a user nor, until now a builder of HTTP APIs so stumbling around, but these crates do a decent job of being usable even to a novice.
I really shouldn't be let loose with all this
Hey, folks! I’m looking for a Staff Software Engineer to join my team (API Core) at #Mailchimp.
Some of the things we work on: #PHP, #REST, #OpenAPI, #OAuth2, #APIGovernance, and more.
We are stewards of our public #APIs, and we collaborate with other capabilities teams to ensure APIs are developed according to our standards and processes. You would work directly with me on a daily basis.
This position is in Atlanta or New York.
https://jobs.intuit.com/job/atlanta/staff-software-engineer-api-core-team/27595/76329932512
I’ve recently taken a closer look at the #Foursquare #API (updating the long unmaintained Platypush plugin, details on why coming soon).
At first their new API versioning schema seemed a bit confusing (why would anyone use arbitrary YYYYMMDD
strings as versions?), but a closer look at how they implemented it revealed a quite clever design decision:
Versioning is controlled by the
v
parameter, which is a date that represents the “version” of the API for which you expect from Foursquare. It is designed to give developers the freedom to adapt to Foursquare API changes on their own schedule. The value of the v parameter is a date in YYYYMMDD format that lets you tell us “I’m prepared for API changes up to this date.”
You know when you look at an engineering decision that is so elegant and obvious that you think “damn, how could nobody think of this before?”
Nearly two decades spent managing /v1
, /v2
, /v2.5
, /v2.almost3
, /v3
, managing migrations and deprecations, documenting breaking changes, introducing exponentially thicker layers of schemas and converters, and the obvious solution was just there under our nose.
Why don’t you just start with defining the base schemas of your API objects at the time of their first release, and then every time you add, modify or delete a field, or change some return type, or add a value to an enum, you just version the change with a timestamp?
Let the developer say “I understand the language that your API spoke 3 months ago”, and you just dynamically create the schemas, GraphQL or ORM snippets to parse requests and responses as of that date.
No more breaking changes. No more forced migrations. No more boilerplate to explicitly convert payloads across different API versions.
You construct the response by first applying the base schema, and then gradually patching it - just like you would do with a git rebase, or an ORM migration tool.
A downside may probably be that you can never really delete a column from the db if it was ever used by any version of your API.
And a challenge may also be to adapt tools like #OpenAPI / #Swagger that were designed around static schemas to also work with “dynamically versioned” selections.
But to me the problems it solves far outweight the downsides.
A coalition of European cloud providers, including Aruba, IONOS and Dynamo, has introduced the Sovereign European Cloud API (SECA), a new open standard for cloud infrastructure management.
Lapidary-render 0.12.0 is now released.
To the best of my knowledge it's the only #codeGenerator that properly handles #jsonSchema anyOf and allOf.
Also has support for oneOf, but not per the specs.
https://github.com/python-lapidary/lapidary-render/releases/tag/v0.12.0
Cool, ik kende usingRecursiveComparison() en assertSoftly() nog niet. #AssertJ
En je eigen #RestAssured testApi via #OpenApi ook niet.
Verder waren deze testlibraries en #WireMock wel bekend en #Awaitility enigszins ook.
I learn that, to participate in #OpenAPI, you need Slack (and leave your personal data to this company) :-(
SDO (and free software projects), please allow participation *without* registering to centralized silos.