API Intersection

Michael Hibay has moved between huge companies with complex needs, and others that are just starting out. He says that some key lessons of API design are true for organizations of all sizes.

Between September 2020 and April 2021, Michael was the Senior Engineering Manager at Capital One. He’s now CTO of startup Vesti, a social network and chat app for investors. 

Michael believes that however big or small a company is, they should start designing APIs from the outside in. By that, he means design for the end user, and leave room for future additional complexity. This will save your developers time and effort creating APIs that ultimately don’t serve a business-centric purpose, and limit the issues you encounter as you scale.

On this episode of API Intersection, Michael talks about the pros and cons of hypermedia, why developers and the business side benefit from working together, and how to create a shared vocabulary that becomes the foundation of your organization’s API design.

Do you have a question you'd like answered, or a topic you want to see in a future episode? Let us know here:
https://stoplight.io/question/

As leader of the Developer Advocate program at work management platform Asana, Jeff Schneider takes the open part of “open API” very seriously.

Jeff acts as a mediator and translator for different developers who are building and using APIs to connect with Asana and personalize their experience. He believes getting feedback from each type of developer is key to improving their interactions with the platform. 

Asana categorizes developers into three categories: Third-party developers work for companies that need to create integrations with Asana; second-party developers are customers of Asana’s platform, who need to customize the service in some way with an API; first-party developers include people and teams inside Asana who are building APIs for the platform to suit their own needs. 

On this episode of API Intersection, Jeff explains Asana’s robust feedback process, why pre-COVID he met up with Asana customers in person, and how he got even the non-technical teams to love APIs.

Do you have a question you'd like answered, or a topic you want to see in a future episode? Let us know here:
https://stoplight.io/question/

If you have a vision of the API model you’d build if you had almost unlimited funds and 4,000 developers at your disposal, you’re probably very jealous of Jay Jena. 

Jay’s resume includes designing network management services at Cisco, and the private cloud architecture at Toshiba India. Now, he’s Head of APIs at a little company called PayPal.

The key tenet of Jay’s API strategy at PayPal is that the whole system must be scalable. PayPal APIs are all created using a single detailed design guide. As an extra guard rail against human error, every API is run through a linter, which checks for mistakes.

On this episode of API Intersection, Jay explains which factors he takes into account when deciding whether a particular API is worth building, why a softly-softly approach to deprecation is necessary when you’re working with money, and the time-saving power of PayPal’s API linter.

Do you have a question you'd like answered, or a topic you want to see in a future episode? Let us know here:
https://stoplight.io/question/

With a career based on guiding the uninitiated through the world of APIs, it’s not surprising that Erik Wilde, API expert at Axway, thinks the space has gotten too technical.

An insider who spends a lot of time talking to people on the outside of the API development process, Erik is particularly well-placed to see the disconnect between the end users and the developers.

More often than not, developers are the only ones involved in the process of building APIs from scratch, even though they won’t be the only ones using them. 

This creates confusion and even suspicion on the business side. And if you don’t think about your end goal first — based on the user's needs — you might miss it.

On this episode of API Intersection, Erik explains why the technical aspects of API development are ultimately less important than creating something that’s actually useful, why he isn’t Team REST or Team GraphQL, and why big companies struggle to standardize terms.

Do you have a question you'd like answered, or a topic you want to see in a future episode? Let us know here:
https://stoplight.io/question/

An early proponent of APIs, Dilip Krishnan has seen the technology grow legs, learn to walk and start to run. 

Dilip is currently Engineering Manager at Oracle, and has previously worked as a senior consultant for American Airlines, CIBER and Geniant, to name a few. 

Like many developers, Dilip has his own views on certain approaches: for example, code-first vs. design-first, microservices vs. SOA, or the importance of hypermedia capability. 

He’s seen the passionate arguments people get into around subjects like this. And he says that convincing a team to unite around one viewpoint requires a skill set many developers don’t appreciate when they sign up for the job: the art of persuasion.

On this episode of API Intersection, Dilip explains why a company culture that encourages criticism can help move everyone forward on APIs, why documentation is not just nice to have but necessary, and the pros and cons of starting with design over code.

Do you have a question you'd like answered, or a topic you want to see in a future episode? Let us know here:
https://stoplight.io/question/

One concern holding companies back from embracing microservices is the investment they’ve made in their monolithic architectures. Ultimately, the benefits outweigh the costs, says Sophie Rutard, head of documentation management; identity and access management; and API developer relations at credit insurer Euler Hermes.

As Sophie says, her different responsibilities sound unrelated at first glance. But because the company functions on a microservice architecture, they all interact naturally. 

“It's all APIs that we built: some are part of the document area, some are the backbone of our IT infrastructure, because it's the authorizations for our APIs. And then we expose them on the developer portal that we have built. And that's where it comes all together,” she says.

On this episode of API Intersection, Sophie talks about the challenges of transitioning a nearly 100-year-old company to a new idea, negotiating over your style guide, and seeing APIs as a constant work in progress.

Do you have a question you'd like answered, or a topic you want to see in a future episode? Let us know here:
https://stoplight.io/question/

A good API is like a LEGO block — or so says Matthias Biehl, author and advisor to API-University. The bumpy side is the easy-to-understand front-end; the underside connects multiple bricks together to create endless possibilities.

Simplifying the often complicated realm of APIs is part of Matthias’s mission. When designing your API, the simpler the better, he says.

Ironically, it’s when a company starts accessing more resources that this “Keep it simple” mantra often falls by the wayside. Adding more people into the mix dilutes the consistency you get when only one person is in charge of designing and building. 

On this episode of API Intersection, Matthias explains why intuitive APIs should be the goal, why simplicity is a gift to your end user, and the difference between hunters and fishers in the context of APIs.

Do you have a question you'd like answered, or a topic you want to see in a future episode? Let us know here:
https://stoplight.io/question/

Jason and Adam answer these listener questions in today's episode:

• Question 1 - Do you have any tips and ways to solicit feedback from potential customers of an API product?
• Question 2 - Is a design first approach more beneficial than a code first approach and what makes developers choose one or the other?

Listen in to hear Jason and Adam's thoughts on these, and visit https://stoplight.io/podcast/ to submit a question you'd like answered in a future episode.

Do you have a question you'd like answered, or a topic you want to see in a future episode? Let us know here:
https://stoplight.io/question/

The fundamental purpose of an API is to connect applications — so don’t let the implementation process create organizational disconnects, says James Higginbotham, CEO and founder of API consultancy LaunchAny.

API development has come a long way since its Wild West early days, when the only people who paid any attention to APIs were the developers and engineers building them. Now, APIs have significant potential across departments, not to mention as external products. 

This is a great opportunity, but also means that developers can’t plug in, tune out, and emerge weeks later with something they’ve cooked up alone. There has to be consultation with the end users, who might have a very different vision and set of needs than developers appreciate.

On this episode of API Intersection, James explains how to build bridges between developers and the other stakeholders, why you should consider creating a position for an API platform manager, and how to start formalizing your APIs with an eye on the future.

Do you have a question you'd like answered, or a topic you want to see in a future episode? Let us know here:
https://stoplight.io/question/

On our very first Q&A episode of API Intersection, Jason and Adam dive into a listener's question about GraphQL, including its emergence, pros and cons, and a few helpful use cases.

Do you have a question you'd like answered, or a topic you want to see in a future episode? Let us know here:
https://stoplight.io/question/