API Builder [https://www.apibuilder.io] integrates many of the end to end tools teams need to manage APIs at scale. JSON remains first class and support for swagger is native (also supports avro idl… protobufs to come).
API Builder was started in 2014 as a free and open source project to build a community around best practices we learned scaling gilt.com and building flow.io.
Managing great APIs end to end at scale and over time take a huge investment in culture and tooling. API Builder solves a number of those problems.
A few reasons why teams adopt API Builder.
- Very, very high quality generated clients: Teams that use API Builder end up relying 100% on the generated clients - ie. the developers STOP writing and managing their own client SDKs, freeing up time to focus on product improvements.
- Resource centric: API Builder is resource first - instead of defining an operation explicitly, you define resources and then expose operations on that resource.
- Simple service specification: API Builder at its core separates the notion of the input format (e.g. api.json, swagger, avro) from the service description (service.json). This is a huge advantage: regardless of input format, the service specification can be fully expanded and complete.
- Simple input format: The default api.json format is simple for humans to write. It is JSON, but more than that it is approachable by a novice and designed to be both simple and easy.
- Easy to add code generators: Code generators in API Builder are themselves REST services which accept a service description (in JSON) and essentially return a string. Teams often write their own code generators - even small disposable ones - to systematically solve problems in an automated fashion.
- Testability of clients: With generated mock clients built from the same interface definition, teams can rely on mocks when building automated tests - and further use the provided mock clients to override only the specific features needed for a given test.
- Workflow that works with micro or mono repos and allows for concurrent, branched development of spec, service and client
API Builder was started in 2014 as a free and open source project to build a community around best practices we learned scaling gilt.com and building flow.io.
Managing great APIs end to end at scale and over time take a huge investment in culture and tooling. API Builder solves a number of those problems.
A few reasons why teams adopt API Builder.
- Very, very high quality generated clients: Teams that use API Builder end up relying 100% on the generated clients - ie. the developers STOP writing and managing their own client SDKs, freeing up time to focus on product improvements.
- History: Every change in spec is documented - accurate and automatic - e.g. https://app.apibuilder.io/history?org=apicollective&app=apib...
- Resource centric: API Builder is resource first - instead of defining an operation explicitly, you define resources and then expose operations on that resource.
- Simple service specification: API Builder at its core separates the notion of the input format (e.g. api.json, swagger, avro) from the service description (service.json). This is a huge advantage: regardless of input format, the service specification can be fully expanded and complete.
- Simple input format: The default api.json format is simple for humans to write. It is JSON, but more than that it is approachable by a novice and designed to be both simple and easy.
- Easy to add code generators: Code generators in API Builder are themselves REST services which accept a service description (in JSON) and essentially return a string. Teams often write their own code generators - even small disposable ones - to systematically solve problems in an automated fashion.
- Testability of clients: With generated mock clients built from the same interface definition, teams can rely on mocks when building automated tests - and further use the provided mock clients to override only the specific features needed for a given test.
- Workflow that works with micro or mono repos and allows for concurrent, branched development of spec, service and client
More at https://www.apibuilder.io/ and https://app.apibuilder.io/doc/why
[edit: formatting]