Over a million developers have joined DZone.

What Do Developers Need To Know About APIs and Integration?

DZone's Guide to

What Do Developers Need To Know About APIs and Integration?

There is a broad range of concerns about integration and APIs, with the most predominant being security, tools, and being business-centric.

· Integration Zone ·
Free Resource

Building integrations to CRM applications? Find out eight things that each product manager and technical executive should know in The CRM Integration Guide: 8 Things Experts Are Considering in Their API Strategy.

To gather insights on the state of integration, API design, and API management, we spoke with 19 executives who are familiar with integration and APIs and asked them, "What skills do developers need to ensure their code and applications integrate well?"

Here's what they told us:


  • Read the documentation and use the API as intended. Have “lego-ability.” Understand how the little blocks work and then build APIs that enable someone to use their imagination to create something you haven’t imagined. Expand beyond the traditional view of the customer. Identify the pain you’re in the unique position to solve. Learn to recognize where there’s emotional relevance. Anticipate what will generate great emotional resonance.
  • 1) Developers need to design and build APIs with documentation. It’s important to figure out how to use APIs and how to build them without bugs. 2) Design to expose business functionality through APIs.
  • 1) Come up with simple, clear and comprehensive data models to represent the problem being solved by the application. 2) Expertise in building representations of the data and operations performed on it in multiple different formats. 3) Abstract thinking to expose capability of their application to be consumed as multiple API calls. 4) Equally, wear the consumer hat and design API that consumers want and are useful for them. 5) Awareness of the standards: build solid expertise on the standards and provide a robust and secure implementation of the API. 6) Have the empathy to spend an equal amount of effort in documenting the API to ensure widespread adoption.
  • Proficiency in multiple languages. Often APIs come with SDK and examples of use in lieu of documentation. Be ready to dive into a language you don't use every day to understand how this API works. And of course, writing functional tests is the fastest way to know when something goes wrong in your application.
  • When providing an API, developers need to step back and consider how different users may want to use their service, making sure that they expose all the features that will meet those needs. Use open standards, such as HTTP, wherever possible – to minimize what developers need to learn. To make people more successful with your APIs, provide great documentation, with easy to follow tutorials for common tasks.

API Design

  • Learn API design. Follow frameworks. Understand use cases and treat endpoints that address those needs. API scaling. OAUGH more seamless for authenticating versus service. Understand web hooks and exposing them for real-time integration. Properly documenting APIs.
  • Be aware of, and knowledgeable about, the shift to microservices with APIs and the DevOps methodology. Compute logic, move at pace, prepare for mid-course corrections. Be flexible. Always be learning. Help innovate. Understand the business, not just the technology. Developers are empowered now. They can lead the organization but they must have a more holistic view.
  • Developers need to well-versed with HTTP and the principles of REST. Working knowledge of at least one web framework in the language of their choice is important. Knowledge of web-based technologies like HTML and JavaScript is also important where an API allows developers to add UI elements.
  • Think about integration in a sustainable fashion. Think about building APIs that will be around for 10 years versus two years. Think about building long-lasting API code. Ensure stakeholders are aligned with common goals.

API-First Mentality

  • Take an API-first approach. Lay out how you will expose as an API. Think about API implications. Create a contract first then create a service to ensure people have the best experience. Use tools to simplify integration and adoption (service registry and discovery, configuration management) no hard-coded parameters. Configuration management tools simplify adoption of new architectures to move fast and fail fast. The cost is well justified. Simplify integration between platforms, architectures, and choreographing the services you are creating.
  • API is the boundary. Whatever is behind the API is less important. Start to do contract-first design. Write the API endpoint first and determine how people will interact with it and then work backward to implement the backend.
  • Access Apiary.io a developer-centric tool for forceful API development and to create great experiences for consumers. Great place to start focusing on API design first. Run tests before implementing the backend. Use to connect back to DevOps tools to release early and often. Learn from your failures quickly. Get it to the consumer to learn what works and what doesn’t.


  • Meeting external data sources where they live requires a willingness to dive into unfamiliar systems, environments, and languages. We specialize in Clojure, but everyone on the team is encouraged to be a polyglot, training tools like Exercism.io are invaluable for this. Whatever language you use for your own systems, make sure it has a good story around data manipulation. Look at the simplest case: if it’s a pain to parse a CSV, all the cool asynchronous microservices in the world aren’t going to help you. Embrace standards and open-source technology. Vendor lock-in is something integrators work hard to overcome, we shouldn’t be adding to it. HTTP status codes are not a form of personal expression, use the right ones.
  • Use well-defined interfaces when it comes to getting data. Modularize and focus on business logic independent of the integration layer. Look for tools and platforms that do API creation for you. Use tools to expose data for you – in three fields, not 3,000.
  • User experience (UX) design must be part of the product creation process. Most developers understand what it takes to use APIs, but experience design is the weak point. Additionally, developers need to understand what it takes to operate and scale cloud services, especially if they sit in between multiple SaaS providers to glue capabilities together.
  • Dogfooding. Use your product to automate and make integrations seamless. Use your integration internally to learn its strengths and weaknesses, and how to improve it, before sharing it with your customers.
  • Having a microservices-based modeler. If not, you cannot be successful integrating multiple systems. Automation QA is key to testing and development when integrating with a lot of applications, defining services, and automating testing of integration.
  • We’ve worked hard to provide means for architects and developers to collaborate in building reusable connectivity using service API connector parametrization, generate design-time object structures that allow developers to work with payloads using point-and-click rather than to resort to expressions, and build process and service API interfaces that are easy to consume at design time and runtime. And, given that we take care of the integration heavy-lifting, what developers need to think about, for example, is how to handle errors that fall outside of the happy-path. Getting the benefits of these platform capabilities and getting the level of reuse that service-oriented or micro-service initiatives seek mandates discipline in the way that graphical process “code” and connectivity is consumed by others. Knowing how to design and architect for others to use and, for example, handle errors and propagate these “up” in a meaningful way so that these are actionable by the caller are the types of skills that developers and architects should put in practice. Simple-to-use integration tools don’t free you up from good design practices.

What else do you think developers need to know about integration, API design, or API management?

Here’s who we talked to:

  • Murali Palanisamy, E.V.P., Chief Product Officer, AppViewX
  • Kevin Fealey, Director of Automation and Integration Services, Aspect Security
  • Max Mancini, VP of Ecosystem, Atlassian
  • Shawn Ryan, V.P. Product Marketing, Digital as a Service, Axway
  • Parthiv Patel, Technical Marketing Manager, Built.io
  • Chaitanya Gupta, CTO, Flock
  • Anwesa Chatterjee, Director of Product Marketing, Informatica Cloud
  • Simon Peel, CMO, Jitterbit
  • Keoki Andrus, VP of Products and Steve Bunch, Product Manager APIs and Integrations, Jive
  • Rajesh Ganesan, Director of Product Management, ManageEngine
  • Brooks Crichlow, Vice President, Product Marketing, MongoDB
  • Derek Smith, CEO, Naveego
  • Guillaume Lo Re, Senior Software Engineer, Netvibes
  • Vikas Anand, V.P. Product Management and Strategy – Integration, Oracle
  • Keshav Vasudevan, Product Marketing Manager, SmartBear
  • Kevin Bohan, Director of Product Marketing, TIBCO
  • Pete Chestna, Director of Developer Engagement, Veracode
  • Milt Reder, V.P. of Engineering, Yet Analytics

Your API is not enough. Learn why (and how) leading SaaS providers are turning their products into platforms with API integration in the ebook, Build Platforms, Not Products from Cloud Elements.

integration ,api design ,api management ,career ,career development

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}