eupolicy.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
This Mastodon server is a friendly and respectful discussion space for people working in areas related to EU policy. When you request to create an account, please tell us something about you.

Server stats:

228
active users

#openapi

3 posts3 participants0 posts today

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 openapi.tools/ I found stainless.com/ and apparently OpenAI is using this to generate their API client. Which is pretty good indicator.

Any recommendations?

openapi.toolsOpenAPI.Tools - an Open Source list of great tools for OpenAPI.OpenAPI.tools is a comprehensive and open source list of resources for developers working with OpenAPI.

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

🚀 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: devfest.gdgpisa.it/talk/overla

Hope to see you there! 🎉

devfest.gdgpisa.itDevFest Pisa 2025Together We Grow, Together We Build! 🌱 Unisciti alla DevFest Pisa, l’evento che riunisce la community tech per crescere e innovare insieme! Talk ispirazionali, workshop pratici e networking con esperti del settore. Perché solo insieme possiamo costruire il futuro della tecnologia! 🚀

"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."

gist.github.com/briandominick/

GistAPI Documentation Decision MatrixAPI Documentation Decision Matrix. GitHub Gist: instantly share code, notes, and snippets.
#API#APIs#APIDesign

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.

jobs.intuit.com/job/atlanta/st

Software Engineering Careers at IntuitStaff Software Engineer (API Core Team)Learn more about applying for Staff Software Engineer (API Core Team) at Intuit

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.

https://docs.foursquare.com/developer/reference/versioning

DeveloperVersioningVersioning 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 forma...