Non-technical API Design Should Be Possible
Most people who believe they work in API Design aren't. What they're actually doing is technical work on API definitions. API Design is still very focused on syntax, semantics, schemas, external references, attributes, error codes, you name it. All these things are important and necessary. However, they're not what API Design should be about. API Design lives at a level of abstraction above all the technical toil needed to make APIs work. Designers translate what consumers need into a plan of what an API should be. What are the tools and processes that can help? Stay with me to explore.
Speakeasy provides you with the tools to craft truly developer-friendly integration experiences for your APIs: idiomatic, strongly typed, lightweight & customizable SDKs in 8+ languages, Terraform providers & always-in-sync docs. Increase API user adoption with friction-free integrations.
To me, non-technical work is everything where I don't need to manipulate code or engage in any sort of machine configuration. Writing this text, for example, is non-technical work. Using a GUI to prioritize feature requests is also non-technical work. In essence, the work that happens to design what an API should be is non-technical. However, the work to define how an API behaves becomes technical. Identifying and documenting the functionalities of a new API is non-technical work. Creating an OpenAPI document for a new API is technical work.
