#apifirst — Public Fediverse posts

API-First Architecture is rapidly becoming the standard for connecting software with AI agents. By treating APIs as first-class products, organizations gain faster time-to-market, clearer contracts, and more secure, scalable integrations. Read the full analysis and practical takeaways on the blog: https://wix.to/GALIfVk

#AI
#APIFirst
#Integration
#Architecture
#EnterpriseTech

What are your thoughts for an #APIfirst #REST API approach but giving API users access to some aggregations.

In the current #BFF based solution our dashboards and some filter dropdowns especially make use of materialized views that are fairly complex UNION/GROUP BY combinations.

I guess we will just have a few specialized endpoints for this and depending on performance impact decide if to include those in the public API or not.

Организационные и технологические трансформации в банке глазами корпоративного архитектора

Корпоративный архитектор — это «демон Максвелла», и его задача — бороться со сложностью ИТ-ландшафта. У нас в Банке это добрый демон, оперирующий подходами Just Enough Enterprise Architecture (JEEA) и Lightweight Architecture Governance (LAG). Именно корпоративные ценности и культура в Банке делают демона добрым. Поверьте мне, ведь я один из них. Привет, Хабр! Меня зовут Дмитрий Клецких. Я Chief Enterprise Architect в Райффайзен Банке. До этого много лет работал корпоративным архитектором в других компаниях: МКБ, СБЕР, Транснефть, Правительстве Москвы. Поговорим об изменениях ИТ-ландшафта, организационных и технологических трансформациях, о роли архитекторов и изменении этой роли с приходом ИИ.

https://habr.com/ru/companies/raiffeisenbank/articles/957316/

#enterprise_architecture #platform_engineering #lag #apifirst #greenpath #jeea #цифровая_трансформация #архитектурное_мышление #ии_в_разработке #ITстратегия_банка

Pessoal,

Estamos iniciando um projeto open source chamado vitae, a ideia é ser o seu curriculo vitae, online, no fediverso.

Será um linkdisney-like, federado, pensando na pessoa profissional, e no ser humano por trás dela.

Não vai ter timeline com coach quântico, até pq já temos o mastodon pra isso né, mas as mudanças no currículo poderão aparecer na TL ou não, de acordo com oq a pessoa usuária quiser mostrar.

O Backend vai ser PYTHON com FASTAPI e quem tá puxando os requisitos e arquitetura é o Dr. @riverfount

O Frontend vai ter o melhor e mais moderno do JS/Deno, quem tá puxando os requisitos e arquitetura é o senhor @jedi.

Eu to cuidando da INFRA.

Quer entrar e ajudar a criar essa maravilha? só vem! ;)

Tem ticket pra todo mundo! :P

Estamos nos organizando o role via https://mattermost.bolha.chat

Aqui o convite para entrar!

https://mattermost.bolha.chat/signup_user_complete/?id=w543hb3aypgyfjy8eh9x9da8oc&md=link&sbr=fa

Canal #vitae e #viate-dev

cc @dunossauro , se puder repassar pros seus alunos, pode ser uma oportunidade de participarem de um projeto open source do zero.

cc @melissawm
cc @ericof

Pythonistas, espalhem!

JSistas, espalhem!

BOOST PLS

Uma iniciativa Bolha.io/Bolha.us

#Bolhaverso #APIFIRST #PYTHON #JS #DENO #CLOUDNATIVE

Here's an interesting interview with Viktor Farcic from Upbound talking about going #APIFirst for internal developer platforms. Even if that's not your thing, the last part where he talks about how #MCP should relate to #APIs as a value-add is relevant way beyond his domain. https://nordicapis.com/why-internal-developer-platforms-need-apis/

"[T]he vast majority of MCP servers are a waste of time. And that’s normal because the MCP spec is only months old. People jump into it, and they start building for MCP without really thinking it through or understanding what it should be.

The vast majority of MCPs that you can see now are reflections of APIs. I think that’s a complete waste of time. This might be offensive, but let’s take Kubernetes. As an example, Kubernetes is an API-driven platform of sorts. Now let’s say you have a Kubernetes MCP server that basically allows you to get resources, to describe resources, and to see the logs and so on and so forth. They’re basically reflections of the Kubernetes API, just as kubectl is a reflection of the Kubernetes API.

Now, does an AI agent really need that MCP server? Absolutely not. It’s perfectly capable of using kubectl directly. And even if there weren’t a kubectl CLI, it’s perfectly capable of talking to the API as is. And it’s not hard for an AI backed by an agent to execute the URL commands to go to some API, and effectively do the same thing that that MCP server is doing.

What we need is MCPs that are actually providing additional value around user intents. Instead of having a Kubernetes MCP server that is a reflection of its API, have a Kubernetes MCP that will have certain logic or workflow or this or that, that will help you combine resources to get an application up and running. So, something beyond just a one-to-one reflection of an API."

https://nordicapis.com/why-internal-developer-platforms-need-apis/

#APIs #APIFirst #MCPs #AI #GenerativeAI #AIAgents

Kontur Population
Not just a map — a population data engine.

Kontur Population is always up-to-date, API-first, and fully customizable.
Built for decision-making across sectors — from disaster response to logistics & insurance.

🔗 kontur.io

#GIS #GeoData #PopulationMap #APIFirst

Pārstāju te tik bieži rakstīt, jo gribēju uzrakstīt savu Twitteri/Mastadonu. Bet vēlme to padarīt vairāk kā "make it simple, make it work", ir jau aizgājusi kāda ntā iterācija. Beigās (pagaidām) ir parasta pierakstu web aplikācija bez skaistās daļas, tikai #API (jā, #APIfirst piekritējs) un izdzēsu visu #ActivityPub un #ActivityStreams... jo tie izrādās ir vienkārši. Tagad jāpārtaisa vecāka vibe-coded "skaistā" #ReactJS puse. Un tad mobile + desktop. Un tad... :)

Here is a discussion how the request validation middleware should handle paths that are not defined in your #openapi API description. – Return 404 or skip the validation and pass the request to the upstream app?

Your thoughts would be very much appreciated.

https://github.com/ahx/openapi_first/issues/350

#ruby #rack #apifirst #openapi_first

openapi_first 2.7.0 was released with better support for handling multiple APIs, including an RSpec integration, and an option to adjust the request path used for validation.

https://github.com/ahx/openapi_first

#Ruby #Rack #APIfirst #openapi #openapi_first

I had a blast yesterday chatting with Derric Gilling, recording a session for the #Moesif "APIs over IPAs (How to Build an API-first Business)" podcast. I shared a bit of how we built our #API program (and #APIFirst culture) at Apiture.

"Moonwalk – 2025 update"
https://www.openapis.org/blog/2025/02/05/moonwalk-2025-update

#openapi #Moonwalk #APIfirst #specfirst

I am working on adding "coverage" to the openapi_first rubygem.

This can be used to see if you have tested all requests/responses in your OpenAPI API description.

Please check it out. Any feedback on this would be greatly appreciated: https://github.com/ahx/openapi_first/tree/coverage?tab=readme-ov-file#test-coverage

#openapi #specfirst #apifirst #ruby #rack

Navigating OpenAPI, TypeSpec, and API-Drift in the "Post-OpenAPI Era"

https://netapinotes.com/navigating-openapi-typespec-and-api-drift-in-the-post-openapi-era/

"In a perfect world as an API program lead, I would like to see a run-time comparison, per request, between what the API is doing and what it purports to do." -- #MatthewReinbold

#api360 #APIFirst #specFirst #typeSpec

@teixi @mamund @allenholub When adding a new API endpoint I start with writing an OpenAPI description and review, refine it with others. We are using the API description for request validation and parameter parsing. On production. We run response validation through the API description during testing.
This helps a lot to keep your docs and implementation aligned.
This #APIfirst #DesignFirst approach works nice and I would like more people to talk about it.

Hey my ruby gem "openapi_first" just hit 100 stars 🌠 on Github. Yay!

openapi_first is a library to make sure your API implementation is aligned with your OpenAPI API description. And it also comes with a rack middleware to do request validation through your OpenAPI API description. Wow! 🚀

Feedback would be much appreciated. Please check it out at https://github.com/ahx/openapi_first

#ruby #openapi #designfirst #apifirst #api

Design-first means that you describe your HTTP API (with OpenAPI) before writing any line of server code.
Now there are libraries to turn your API description into a request validation middleware. On production. With that, you not only have reduced the LOC required to implement the API, but also make sure that your API description matches your implementation. Great, right?

I'd like to learn why most APIs still are not build that way. Any thoughts?

#openapi #APIfirst #DesignFirst #apidesign

I just released version 2.0.3 of openapi_first, which makes the test assertion method work as described and adds an option to the request validation middleware to skip the error response. This option can be useful in a code-first scenario where you want to subscribe to invalid requests / responses according to your API description.

#ruby #openapi #apifirst #openapi_first

https://github.com/ahx/openapi_first

I am working on adding test coverage to openapi_first and this is how it looks so far. I am wondering if it should complain about untested 4xx, 5xx responses by default if they are described for the request or just skip them. 🤔

#ruby #ContractTesting #APIfirst #OpenAPI

openapi_first is a request/reponse validator for OpenAPI: https://github.com/ahx/openapi_first

I am working on adding test coverage to openapi_first and this is how it looks so far. I am wondering if it should complain about untested 4xx, 5xx responses by default if they are described for the request or just skip them. 🤔

#ruby #ContractTesting #APIfirst #OpenAPI

openapi_first is a request/reponse validator for OpenAPI: https://github.com/ahx/openapi_first

I am working on adding test coverage to openapi_first and this is how it looks so far. I am wondering if it should complain about untested 4xx, 5xx responses by default if they are described for the request or just skip them. 🤔

#ruby #ContractTesting #APIfirst #OpenAPI

openapi_first is a request/reponse validator for OpenAPI: https://github.com/ahx/openapi_first

While they were pretty much en par in past releases openapi_first 2.0 is finally a bit faster than committee.

https://gist.github.com/ahx/e6ffced58bd2e8d5baffb2f4d2c1f823#openapi_first-200

#ruby #apifirst

openapi_first is a Ruby gem for request / response validation and contract-testing against an OpenAPI API description. It makes APIFirst easy and reliable.

Version 2.0 has just been released. 🎉

New features:
- Hooks like `after_response_validation`, which you can use for metrics for example
- Test assertion method `assert_api_conform(status: 200)`
- Performance improvements

Check it out: https://github.com/ahx/openapi_first?tab=readme-ov-file#openapi_first

CHANGELOG: https://github.com/ahx/openapi_first/blob/main/CHANGELOG.md

#openapi #ruby #APIfirst #DesignFirst #rails

I just leared that there is another OpenAPI validator in Ruby world called skooma! This introductory post also mentions openapi_first.

https://evilmartians.com/events/let-there-be-docs-a-documentation-first-approach-to-rails-api-development

In the linked talk Svyatoslav Kryukov also talks about the advantages of API-first instead of code first.

#ruby #openapi #APIfirst

Design-First API Development: Myth or Reality?

https://nordicapis.com/design-first-api-development-myth-or-reality/

"[W]e will look at where developers stand on this concept via the feedback on this thread, and we’ll present four very clear takeaways on design-first." -- #KristopherSandoval

#apiDesign #apiFirst #api360

@pete @matthew

I first saw "API First" in a 2009 post from Kas Thomas.

https://youtu.be/qGwjqsJtp8E?feature=shared

#apiFirst

Had a blast chatting with @rjrodger this week, recording an upcoming #Voxgig "Fireside chat" on building a robust #APIFirst API program, Developer Relations, #DX, #APIDesign and more. Look for it coming in a few weeks; until then, check out the Voxgig archives! https://www.voxgig.com/podcast

Seriously, Write Your API Spec First

https://www.readysetcloud.io/blog/allen.helton/seriously-write-your-spec-first/

"Imagine you’re building a house. Would you rather the crew draft a blueprint ahead of time and build to that spec? Or would you rather them go off and build your house then create a blueprint of what they built when they were done?" -- #AllenHelton #ReadySetCloud

#api360 #apiDesign #apiFirst

API-First Development: Architecting Applications with Intention

https://thenewstack.io/api-first-development-architecting-applications-with-intention/

"An API-first approach will lead to a faster and more scalable approach to developing software without breaking as many things along the way" -- #AdamKane

#api360 #apiFirst #apiStack

Navigating Change and Cohesion: Transforming Large-Scale API Programs

https://blog.stoplight.io/navigating-change-and-building-cohesion-transforming-large-scale-api-programs

"Building platforms and systems require coherence and cohesion among different teams, languages, vocabularies, and product spaces. Mike recommends finding common ground and establishing a shared vocabulary to enable effective communication, collaboration, and a coherent system." -- #JasonHarmon #Stoplight

#api360 #apiTransformation #apiFirst

🔥⏲️ Fudge Sunday "AI Feel You" A look at recent updates to AI in and around platform engineering and DevX

#ai #llama #llama2 #devsecops #sbom #softwaresupplychain #softwaresupplychainsecurity #DevX #platformengineering #governance #aieducation #aiethics #stem #developerexperience #iac #generativeai #genai #llmops #cloudformation #terraform #aifirst #apifirst #cloudfirst #mobilefirst #privacyfirst #securityfirst #aitraining #aitrends #newsletter #newsletters

https://fudge.org/archive/ai-feel-you/