To gather insights on the current and future state of API management, we asked IT professionals from 18 companies to share their thoughts. We asked them, "What are some real-world problems APIs are solving?" Here's what they told us:
Applications
Our main focus has been using APIs to integrate across applications and with business partners. Organizations are modernizing IT systems by replacing legacy systems with SaaS applications. These new applications need to integrate with other enterprise systems whether modern or legacy. For instance, we frequently work with customers who are modernizing their ERP system, and they need to integrate that new ERP with other systems.
The legacy system was likely a tangle of file-based integrations. With the new ERP, a published API set is the integration point of choice for connecting to all of the other enterprise systems such as general ledger and warehouse management solutions. Additionally, these modernized ERP solutions are able to provide real-time access to enterprise information through their APIs.
We also work with our customers to take advantage of publishing APIs to their partners that provide limited access to this information. For example, a partner wanting to check inventory or check the status of their order can use an API that provides a view into their data directly from the ERP. This can augment the traditional EDI process with API queries for certain transactions that benefit from real-time responses.
Put APIs on top of legacy systems built without APIs in mind. Write code and put API on top to make it easier for customers to interact with them like a CSV file. APIs automatically determine what the file has inside.
Six use cases: 1) Mobile, 2) IoT devices, 3) building out ecosystems – SaaS offering or partner, 4) content or transaction offering (media or ecommerce), 5) APIs as a business (tend to be smaller, the value of the company is monetized via the API), 6) internal agility (80% of API use is internal by large companies how to reuse code more effectively, this is the new SOA, using web APIs to improve internal reuse to achieve agility).
Industries
One client building applications owning the development of the API is Hawaiian Airlines. They build APIs for complex legacy systems that are not API-friendly. Creating APIs required thinking about how to expose and secure the data in the most efficient way. Another good example is in the automotive industry in Europe and U.S. challenge is fragmentation of systems to maintain and new car owners have to go through those systems of onboard and connect cars that are more connected than ever. Register all seven new services at once. Create APIs for systems that did not expose APIs before and also contains PII.
Schiphol Airport started on one use case, improve passenger experience of going through the airport. Thought holistically to make the experience better. There is so much data that’s useful, it became an integration problem. Expanded boarding pass, tracking flights, arrival departure information, flier alerts, to achieve internal agility, they decided to make an API-focused effort to enable the integration of different applications. Opened internal APIs to build a partner ecosystem. Start with the mindset APIs will be open and control access rights.
Other
As a company, we try to be cloud-neutral. On the backend, we can store content in different public object stores. Customers want to maintain their own keys. With key management services from large cloud providers, we can integrate with them as well and give customers a choice of what data they want where.
1) Capital One, one of the world’s largest banking institutions, offers a variety of online financial services including API products. Third-party developers and partners can provide a first-class digital experience for their customers as well as create new revenue streams by using Capital One’s external APIs to open bank accounts, generate personalized credit card offers, and track customer rewards. NGINX technology has enabled Capital One to scale its applications to 12 billion operations per day with peaks of 2 million operations per second at latencies of just 10-30 milliseconds.
2) Adobe, a large software company that develops multimedia and creativity software solutions, uses internal APIs as the primary means of data exchange and communication across various software applications used within the enterprise. Adobe uses NGINX as an API gateway for managing API traffic across all these internal systems.
3) A large technology-focused market research company uses an internal API hub so that its analysts can easily use internal applications to compile, submit, and manage all content they produce. The company is transforming its internal application profile to be more services based and NGINX is providing the required resilience and performance given the mission-critical nature of the applications.
Northwoods need to integrate customer data sources. API-led development and API-led integration are about the more SaaS applications being launched still need to take their data and connect with them. Still an integration use case there, APIs aren’t standard, there’s a variety of ways to connect and integrate. Take advantage of Business Works to consume, connect to a data source and connect to a more common set of services to use with applications.
More easily access information and reduce time to market by 25%. My favorite use case is Netflix. They need to connect with more than 500 client devices, iPhone, Android, X-Box, etc. They have well-normalized APIs that serves metadata from movies, handles search requests, image serving, actual streaming of the movies. But constrained devices over tight networks. They created a middleware backend for front end (BFF) to consume base APIs, contains the majority of the business logic the client needs to use and then opens interface to their own APIs that just serves that client.
When a new client comes on, all they have to do is create a new BFF in the client code and they’re good to go. If the client for one device is no longer needed, they just kill that code off and it doesn’t break anything.
The fundamental problem APIs solves, is answering technical needs with the absolute best solution, in the smallest amount of time, for the smallest cost possible. We provide the best in class Search Experience in the form of APIs. In a matter of minutes — registration time included — customers can answer their Search Experience needs in the best possible way. Doing search right is actually a daunting task; yes, it is possible to spawn up a Solr instance, tune it to best fit a use case, install it on dedicated servers, deal with multi-cluster issues, monitor/operate them...
But at what upfront cost? At what cost in the long run? How many experts will be required for this — how many site reliability engineers, natural language processing engineers? How much time will be necessary for even starting up? For what level of quality? Our customers can just discard these questions. That is what APIs solve in the real world; that is what we do for Search Experience.
Stoplight provides a suite of products to help organizations manage their API design workflows at scale. A critical part of this is building on top of the development workflows that already exist at most organizations. This means integrating with existing tools like GitHub. To do this, we integrate against the APIs that these tools expose.
This allows us to do things like automatically pull information from GitHub into our product, and push information from our products into GitHub. The end result is a much better experience for our customers, and it's made possible because of the rich APIs that GitHub exposes.
Customers are powering use cases from orchestrating real-time integration between endpoints to composing entire business solutions using the Jitterbit Harmony API Integration platform.
1) For example, Odyssey Logistics has orchestrated WIN Logistics — a no-cost, no-fee web-based transportation management solution, powered by Jitterbit to automate the on-boarding of new clients. So when a client registers with WIN, all of their customized configurations are migrated over automatically through an order send and receive API. This means that product lists, shipping origins/destinations, and equipment types are all brought into WIN in real-time.
If a client makes a change in their ERP system, that change is automatically reflected in their WIN environment, in real-time. Additionally, Jitterbit’s API integrations streamline the broker-shipper relationship. So when brokers submit quotes, WIN automatically alerts those shippers without them having to constantly monitor their email. This allows brokers to quickly respond to requests and shippers to easily react to the quote of their choosing.
2) Intellifo, a UK-based company that offers business management software to financial advisers and wealth managers, has connected to over 30 REST APIs of popular endpoints such as Salesforce, NetSuite, JIRA, Aha, Eventbrite, etc. via Jitterbit. One use case they have powered is the Salesforce-JIRA integration through RESTful APIs and webhooks that automatically raises defect tickets from Salesforce and updates bug tracking within JIRA.
Keeping both systems up to date enables easy communication between Dev and Support and has enabled Intellifo to provide multi-channel support to their customer base. Intellifo has also designed a Production Incident slackbot powered by Jitterbit Harmony API Integration platform that consolidates information from systems such as JIRA, Confluence, Salesforce and NewVoiceMedia as it sends appropriate Slack notifications.
1) Most of my customers are security first and foremost. 2) Second is observability to know what’s going on. Now the state of the application is all spread around. 3) People are paying for rate-limiting to prevent hacker from loading your app with requests. 4) The canary deployment releasing update every day.
We built our Mass Customization Platform to allow all Cimpress businesses to leverage the best technologies developed in each. For example, Vistaprint has spent over 20 years building market-leading technologies to solve all the problems involved in sending user uploads to printing presses (from obvious stuff like “is this image high enough resolution?” to more inside baseball like “will the ink in this image bleed together if printed on a particularly glossy surface?”).
Over the past decade, we’ve turned this functionality into a fleet of microservices we call our Prepress APIs. No longer the sole possession of Vistaprint, they are now used millions of times a day across a dozen Cimpress businesses.
Most banks have figured that they have to have APIs. No one really challenges that, and they are in a state of either planning API programs, implementing them or even launching first API products. What we found our clients to struggle with — how do they monetize their API efforts? So FI.SPAN’s approach to that problem is — figure out your client’s use case first and then see what APIs would be needed to solve it.
We spend a lot of time and research effort figuring that out. To give you an example — while some banks were trying out that new API thing via some harmless and non-critical “/GET ATM-locations” kind of APIs we were looking into their most profitable corporate customers’ need and found plenty of use cases which require fairly sophisticated APIs to support account payables as well as receivables, data reconciliation and numerous business automation scenarios. Almost every API we have today is powering some customer facing product.
For data access, we improve security and utility over traditional APIs by supporting newer protocols like GraphQL and SPARQL. Security is improved by embedded the data security rules with the data itself, so any data consumer or other apps don’t need to duplicate security rules and keep them maintained.
Our main customers are marketers and Marketing Technology companies, who used to build software solutions completely in-house. However, the main problem is that getting the data you’d need to build a marketable product would require awfully a lot of time and money.
Marketing requires vast amounts of data in order to be effective, but the costs of collecting and analyzing all this data on own capacities are ridiculously high. And because obviously not every company is able to allocate the required amount of resources to get the software project off the ground, the technological threshold to entering the market was unreasonable.
When the first APIs became available for the marketing community, it was a major game-changer. You can now build a simple keyword research tool in a matter of weeks.
To gather insights on the current and future state of API management, we asked IT professionals from 18 companies to share their thoughts. We asked them, "What are the most important elements of managing APIs?" Here's what they told us:
Protection
Since you are exposing APIs to line-of-business applications, they need to guard against abuse. With two-factor authentication. people try to do fishing attacks. Rate limiting, circuit braking, and timeouts become quite important. Our SLAs tie-in with the other systems they are interacting with. When there is too much load on the system, you need to think about how to shed load. Interesting rules come into play even with APIs exposed out to everyone.
API lifecycle management consists of defining, publishing, securing, routing and mediating traffic, monitoring, and analyzing APIs. The two most important elements of managing APIs are: 1) API Security — according to OWASP Top 10 - 2017, “sensitive data exposure” by APIs is the third most critical web application security risk. 2) Providing a seamless consumption experience via a robust dev portal. According to the 2018 State of API Integration report from Cloud Elements, this is the second most common request from API consumers.
A lot of customers are interested in a different environment and may have moved to microservices which makes APIs a big piece. Security, rate-limiting be in control of how many requests you have. Canary deployment, green/blue deployment, A/B testing is very popular. Have one microservice with the old version of the API and one with the new API. Push the new one and route traffic from 10 requests — one in 10 go to new and then watch the metrics and gradually move everything to the new version. Have security on the gateway side to monitor traffic from the internet. API management is taking the operation logic away from the engineer or developer, it’s done in the proxy itself. The API gateway takes care of security.
Security, then stability. If permission-driven rules are co-resident with the API code, then having an excellent process that keeps security in-sync with your changing data is critical. Secondly, stability, we want to ensure our API users remain backward-compatible.
Ease of Use
There are many important elements to deploying APIs including authentication, protection/availability, and monetization. However, many of those don’t matter if the API is not adopted and used. Ease of use and successfully fulfilling a use case are key to gaining adoption. Our integration platform makes APIs easy to use. Through our application connectors, we can simplify the use of the APIs of many popular software applications. On the API provider side, we give users a second chance to get an API right. A complex API that provides somewhat generalized access to a system can be simplified to satisfy a single important use case (i.e., get my order status).
The last letter in API is “interface” for good reason, and I’ve long felt that the most important thing is to clearly define how you expect that interface to work. How do customers consume your APIs, and how do developers bring those APIs to market? There are a few major architectural decisions you need to make upfront. First, are you planning to go all-in on microservices where your customers are consuming from hundreds or dozens of public-facing APIs, or are you going to wall them up behind a gateway or façade that reduces your surface area? We’ve chosen the former. In our case, you need to put a lot of effort into ensuring standard practices (on everything from authentication to capitalization in responses). If all of your APIs feel like they were developed by different teams, you’re making it harder for customers to adopt more than one. What makes interface definition particularly critical is that a misstep takes years to unwind. Once customers are consuming your API, you have limited scope to make changes without requiring your customers to recode their integrations. And every time you require customers to make a change, they’ll ask themselves why they are working with you and not a vendor that can get things right the first time.
Maintaining consistency in naming and data formats as the number of endpoints grow. It’s not a big deal when you’re providing 5-10 endpoints, but when number gets over a hundred you probably have multiple people (or multiple teams) creating them, over different periods of time, introduced as a part of different products, etc. Having an easy way for all teams to access existing specs is critical. If those specs would be long and difficult to read — it leads to problems. Some questions about formats and conventions we expected to be already solved actually don’t really exist. It’s surprising how many ways are out there to describe sorting/multipage/searches/filtering with multiple parameters. Some standards exist, but after a deep look, we found them incomplete for our use case and had to come up with our own conventions.
Analytics
Communication with visibility. Make it clear what the apps are and how to use them with design, documentation, messaging, and how you sell and market them. Well-designed APIs can fall apart if you do not communicate their value and capabilities. If you manage and own APIs, you need visibility into what’s happening with them, how they are being used, if anything bad is happening. Reports can indicate new and interesting directions in which to take your API program. Do this based on your own metrics and visibility. You have a better chance of succeeding versus copying someone else.
Performance, reliability, and analytics are all important topics in API management. The operational quality of Facebook or Google progressively became the baseline for the delight of end-users and the doom of site reliability engineers. Beyond these, when creating an API-centric business, two rarely mentioned elements are of the utmost importance. The first is maintaining compatibility over time. The purpose of APIs is to have customers build products leveraging them. An API whose form changes — breaks — regularly, alienates customers who have to update their own products in consequence. There are many ways to maintain compatibility while moving forward — versioning and backward-compatible changes being the most common. Yet to be done correctly, the topic must be considered right from the start. Besides, maintaining compatibility generates an extra cost, whether in the form of explicit infrastructure cost when old versions of an API must be kept running, or of implicit maintenance cost when old versions must be regularly patched if not just for security reasons. Another major element of managing API is enforcing security while providing transparency. It is not just about ensuring that the correct people have the appropriate set of permissions to manipulate data anymore. That would be “conventional” security, and while it’s still very relevant and definitely not a solved problem, the topic is relatively well understood. Today, customers expect understanding if not guarantees on the actual use of their data by the company delivering their services. Are their data indirectly leveraged — e.g. by “blind” machine learning algorithms? Can they request their old data to be removed entirely from servers? Can they access all — absolutely all the data their provider is storing about them?
API Lifecycle Management
API Management has the following four major elements: 1. API Lifecycle Management — We believe providing companies the ability to manage the entire lifecycle of API - from designing, developing, publishing, and management of API (that includes retirement/versioning) - thus allowing companies to accelerate innovation by composing innovative solutions, facilitate better security of their enterprise data and allow users to discover and consume your APIs easily. 2. API Gateway — An API gateway acts as a point of entry for a set of APIs. Benefits of using an API gateway is providing the optimal API for each client, reducing the number of requests a client needs to make and enforcing appropriate security and controls. 3. Documentation — The Developer Portal is key to increasing adoption and stickiness of your APIs. It is your initial method of communication with developers. This is the first point where a developer learns and uses your API and is where the developer will learn about the authentication/authorization mechanism. In addition, they will learn which APIs are available for consumption and leverage descriptions and examples for each API request. 4. API Analytics/Monitoring — API Analytics and Monitoring helps companies learn and understand the utilization of their APIs, which can provide insights on the use of various APIs. Alternatively, companies can enforce API quotas, limits, and API traffic throttling to discourage/limit usage that doesn't align with your business goals.
Other
APIs have transitioned from XML-based contracts like SOAP and WSDL to a RESTful format with a little loser definition, using JSON to communicate. Document how it works in a machine-readable format. Define contracts and make them easily consumable by humans and other APIs. Leverage Open API 3, describe APIs in JSON, communicate and understand what the API can do for you and how to communicate with it.
In more than half of the projects, APIs are delivered by clients or third-party services. Make an alignment of deliverables when APIs are being developed at the same time as the application. People are still learning to design, secure, and deliver APIs. APIs are built to be used. When you design, fit the needs of the consumers. Be efficient for a specific use case. Backend APIs can be very different than for a mobile application. A lot of coaching is needed to help developers understand the best practices for APIs in mobile. New standards like graph QL helps with that problem. APIs provide more flexibility for the types and amounts of data.
It is important to anticipate and integrate fallback when an API stops responding or starts to behave differently (like when the API is having a bug). Often, the issue could be easily mitigated by pushing the action to a queue that will be tried again later (like, for instance, sending an email or saving an action), but it's not always possible. Having the application handle such case and indicate with a custom message any issues to the end-user - along with some notification to the development team - is crucial to ensure a well-working service.
There are the usual suspects at runtime, such as security policy management, telemetry and monitoring, and consistent performance. This functionality is more accessible than ever via a number of mature API Gateway products. The most important, and often overlooked, element of managing APIs at scale is a solid API design foundation. It's in developing an API-first culture within your organization that elevates their importance and provides a clear development workflow that results in higher quality, more consistent APIs.
To gather insights on the current and future state of API management, we asked IT professionals from 18 companies to share their thoughts. We asked them, "How does your company use APIs?" Here's what they told us:
Data Access
More data sources are being accessed through APIs. Communicating with APIs for reading and writing data back to those systems. At the core how we develop applications, manage DevOps and communicate with source systems.
APIs are quickly becoming the de facto way organizations deliver value in a digital world. Companies create discrete applications and data sets and expose them as a series of API-enabled services. The customer experience is then highly dependent on the strength of the underlying API architecture. We’ve seen this trend before. Web apps exploded in the early 2000s and then mobile apps earlier this decade. Now, APIs are following suit.
The organizations that master this wave of API development, and deliver compelling experiences via those APIs, will drive a decade of competitive advantage. And as with all new emerging trends, the key to success is part people and process — hiring for API skills and adopting an API-first development practice — and part technology that provides a secure, fast, and scalable API infrastructure.
APIs provide access to data, software, and applications to enable the business to run and applications to provide a better user experience and customer experience.
Our platform is a publisher of hundreds of business banking API endpoints as well as a heavy consumer of other industry and utility APIs ourselves. It’s safe to say that without APIs there would be no platform. We’re in the business of connecting businesses and corporate clients with banks, which is only possible over rich API data exchange. The problem is — every bank today has its own way of offering services to clients, so we had to create that layer to enables the delivery of services to many, in many ways.
In our case — connecting any business application to any bank without the hustle of re-implementing the whole product for every bank and client combination. The current state for many is a file-based exchange with banks over a variety of protocols and formats, which in most cases means a custom project for each client to establish a connection between their ERP and bank services or data.
We use APIs to request permissioned data and perform transactional capabilities.
As the Data-as-a-Service company, we use APIs in two directions: first, for obtaining data from vendors such as Google and Amazon, and second — supplying it to our customers, who, for the most part, represent the Marketing Technology industry.
Internal and External Development
Primarily mobile development and quite a bit of web. There would be no apps or websites without APIs. Integration is a big issue.
We have a cloud-based integration platform that makes extensive use of APIs. Integration historically started with files, then moved to databases and service buses and now rely heavily on APIs. Many modern software applications provide a set of published REST APIs. These provide the perfect integration point as they provide both the transport (HTTPS) and data format (JSON), while the past with files, integration required two distinct sets of technology, a file transport, and a file format. Since many modern software applications publish their APIs, we have built connectors to these applications. The connectors encapsulate the API definition into an easy-to-use package on our integration platform.
A user wishing to build an integration can select two connectors (for example Salesforce and Microsoft Dynamics Finance and Operations) and easily map customer information from Salesforce to Dynamics Finance. For users wishing to connect to APIs that we do not have a connector available, they can set up their own definitions and have our integration platform connect to any API. In addition to these API consumer use cases, we also have API provider capability in our integration platform. This allows a user to define a set of APIs on our platform (for example, to check order status) that they can then make public.
This published API could then be connected to a backend system such as an ERP system. When a customer used the public-facing API published on our integration platform, the API could be connected to the backend ERP including translation and security to provide an update on their order.
We generally don't use the provided kits by the main providers but rather an HTTP library available in our programming language. For us, it's "requests" in Python. We then read the API documentation for each service and implement the calls needed to make it work. We have developed internal libraries to handle our main usage for our frequent library, which includes Stripe, Mailgun, and Intercom.
All the products and services we provide can be accessed via APIs. While we understand the value of web applications to convey meaning in a visual way or to engage with a broad audience, it is in our DNA to first and foremost engage with developers — and we do that by providing them with carefully built and documented APIs to interface their own products with ours.
APIs power every piece of our product ecosystem. We have internal APIs that our web and desktop applications use, as well as public-facing APIs that our customers use to automate and customize their workflows. Beyond our own APIs, we integrate against a number of third-party APIs — from version control systems like GitHub to API gateways like Axway.
We use APIs in two high-level categories: Internal and public APIs for our product offering and front-end applications are backed by a powerful set of APIs. We follow a three-layer API design pattern, including 1) Experience APIs used by our front end to give the experience to our customers. 2) Process APIs where our processing and business logic resides. 3) Systems APIs that use our datastores to access the data. API for our internal IT projects to integrate the systems we use. For internal IT projects, we use the same design pattern as above. However, for these projects, we build the pattern using our own integration and our API manager product, both of which are part of our platform.
Microservices
In the last 10 years, APIs have become the universal language to integrate applications. Monolithic applications kill innovation, it's too slow to integrate new things via the ESB. It's important to have: 1) distributed integration; 2) container-friendly solutions; and, 3) APIs are key to integration. Customers are moving away from choosing point solutions to solve one problem at a time looking for full-service pre-integrated solutions that work.
Enterprises have built monolithic applications with a lot of APIs in one binary. When microservices come along, these are cut into small pieces. Instead of 50 APIs, you will have five. With serverless, it's an API call and then running a piece of code. One API code to call one function. Find the smallest unit of compute shared across monolithic, microservices, and serverless – that’s the APIs.
There are two broad ways: we build (and share and consume) differentiating APIs related to our core business, and for everything non-core, we prefer API-first SaaS vendors. In our domain, we maintain an ecosystem of almost 500 microservices that comprise our mass customization platform. These microservices are used by our portfolio businesses — and third-parties fulfilling orders on our behalf – for everything from artwork preparation to shop-floor optimization to shipping rate calculations.
We’re big believers in providing composable building blocks that our businesses can use to solve problems in novel ways, and we look for the same discipline when buying solutions outside of our domain. Traditional vendors with monolithic solutions expect you to conform to their platform; API-first vendors allow you to integrate their functionality into yours.
Other
Support different types of file services. We use them to manage the content lifecycle, write from ingest to inter archiving, data governance, and so forth. Every platform has to expose APIs to build custom applications and integrations. Within the platform itself, there are many services that use APIs.
In this post, we will take a look at how we can use Google Cloud Vision from a Spring Boot application. With Google Cloud Vision it is possible to derive all kinds of things from images, like labels, face and text recognition, etc. As a bonus, some examples with Python are provided too.
1. Introduction
A good point to start experimenting with Cloud Vision is the Cloud Vision API Documentation. The documentation is comprehensive and the examples actually do work ;-) . In the next paragraphs, we will explore some of the image processing capabilities. We will do the following:
I had the opportunity to meet with Ross Mason, Founder, MuleSoft following his keynote on The Democratization of Innovation.
Companies today are innovating at such a pace no one is able to do it all internally. The next generation of the web is APIs and capabilities. Today, there are tens of thousands of APIs to build upon. There's a great opportunity for innovation by other people on your behalf.
This week, we look into the latest API vulnerabilities in Oracle WebLogic and OnePlus, API security workshop at Black Hat, API security tech landscape, and a new tool for OAuth and OpenID Connect debugging.
The last decade has seen a slew of key technology developments, namely REST/Hypermedia(HATEOAS) and microservices architecture styles, Security (OAuth, SAML, OpenID), Cloud Computing, which have helped facilitate the API driven Digital Transformation initiatives within organizations.
As organizations need to adapt business applications to changing business strategy to be competitive, the need to provide business capabilities via applications on multiple devices(mobile, tablet, web) is urgent and means for easy integration with vendor and partner applications both internal and external is critical.
Whether you're working with on-premise, cloud, and/or third-party integrations, the questions remain the same: What is the client or user experience you need to offer? And how do you align your integration strategy with it? This Refcard explores fundamental patterns for authentication, polling, querying, and more, helping you assess your integration needs and approach the design, build, and maintenance of your API integrations in the most effective ways for your business case.
June is here, and it's hot! Not just high temperatures; it's been a hot month for API news. We are not taking a summer vacation from our API news roundup. In fact, this month we have a special new section about API news in banking. So sit back, sip a cool drink, and enjoy this summary of the latest API news stories.
This week, Samsung has leaked a token that provides full access to their SmartThings code repository, and Facebook fixed one API flaw but got fined for another. We also have a discussion of API security and DevOps and look into a survey that Postman runs on the future of OpenAPI support.
This week, we look into the latest API vulnerabilities in cars, Nagios, and Portainer, as well as different OAuth 2.0 attack scenarios, and the time it takes for attackers to find new API endpoints.
Vulnerabilities and Breaches
Some car owners install hardware GPS tracking devices in their vehicles. These are accessed and managed through mobile apps. Two such apps called iTrack and ProTrack got hacked with about 7,000 and 20,000 users affected respectively. Both of these apps had cloud APIs behind them, had the default password set to 123456, and the API allowed brute force ID enumeration. Attackers could get information on both the car and its owner, such as location, owner name, phone number, address, model, make, IMEI number, etc. With some tracker models, the attackers could have even sent commands to the vehicle, for example, to kill the engine.
This week, we check out the details of the recent API vulnerabilities in Tchap, Shopify, and JustDial. Elsewhere, Gartner reports a whopping 77 percent increase in inquiries on API security. And finally, we take a look at how an API’s OpenAPI definition can be the foundation for API security.
With the increasingly collaborative scenarios in which APIs are used, as well as the growing maturity and scale of microservice architectures, the idea of API coordination has become a hot topic.
Sam Newman and Phil Calçado have popularized the “Back-end for Frontend (BFF)” deployment pattern, which describes a topological approach to coordinating service API calls. However, coordinating API calls in a distributed software system is not a new problem. It has been a concern even from the early days of SOA. In my experience, software architects can often conflate the different types of coordination when trying to determine function placement in their application integration efforts. To help address this pitfall, here is a classification system I use:
This week, Verizon has been patching their home routers, another GPS watch got breached, Shodan added an IoT monitoring service, and we take a look at API security best practices, webinars, and recommendations.
Vulnerabilities
Verizon is urgently updating their Verizon Fios Quantum Gateway home routers. Researchers from Tenable found multiple security issues in the device’s API. For example, HTTPS was not enforced, and some API call parameters were not sanitized. This enabled attackers to sniff logins, decrypt password from its hash, perform a command injection attack, and take control of the device.
I’ve written several blog posts that list out all the changes for each of the most recent releases of Java (JDK 10, JDK 11). With JDK 12 just having been released, it seemed the obvious thing to produce another blog in this series. However, I’ll be looking at the flip side of this latter, focusing on some of the pitfalls that might cause problems, should you want to migrate an application to use this version.
We are now well into the new six-month release cadence and everything is working smoothly. I represent Azul on the Java SE JSR Expert Group, and we decided to switch this version to the revised JSR process. This is not radically different; it's more of a streamlining of the process to fit into the available time more easily.
The world is heading towards a more advanced digital era, and the digital transformation requirements that contemporary organizations require need to be addressed with state-of-the-art, robust solutions that can provide a seamless service to their stakeholders.
Today, where the trend is for organizations to provide services through various apps, there is an exponential increase in the number of apps required to cater to end-user requirements. This has led to the need for businesses to expose more and more data through APIs. Exposing data through APIs facilitate businesses to securely expose content within and beyond the scope of their enterprise. However, due to the proliferation of the number of APIs, organizations face yet another challenge to maintain and manage them. This is where a full API life-cycle management platform comes into play and currently these platforms are available as both on-premises and on cloud solutions.
Organizations increasingly rely on data to serve customers, drive decision-making, and power business processes. This data is typically stored in files, across disparate applications, databases, and local machines and must be moved across the organization quickly to respond to real-time customer demands.
Businesses have long used multiple file transfer protocols and mechanisms to move data for different purposes. They might employ FTP for file transfer between computers on a network, protocols such as AS2 for EDI, and APIs to exchange data between applications. Typically, they have had no centralized or integrated processes for these different types of data exchange.
