Forem: Brenton House

What is API First Strategy?

Brenton House — Mon, 31 Jan 2022 19:10:54 +0000

Understanding API First Strategy and benefits of API-led Integration!

What is an API First Strategy?

API First is more than building an API for every product you have. API First is a strategic and tactical methodology for how you view your products and your business and about adopting a mindset where your products are capabilities that you can deliver. API First focuses on the business value of APIs and what they deliver.

An API First and API-led Integration Strategy is essential to every organization. The companies that are adopting an API First Strategy are the ones that are gaining ground the quickest in the growing API Economy. API First allows you to view your business as a set of API Products that work together to provide the features, data, and capabilities that your organization's products produce.

APIs are what enable businesses to engage with consumers in the digital world and are how your products are going to be judged in the API Economy.

How fast are things moving in the API Economy? Let's take a look.

What happens in a minute?

A lot can happen in a minute.

In a single minute:

UPS will deliver 11,319 packages

Apple will make a little over $70k dollars

In a single minute, over $3 million dollars will be donated to charities around the world.

In the next 60 seconds, over 700K telephone calls will be made.

60 seconds is not a lot of time but it is enough time for a lot to happen.

A lot can also happen in a digital minute

In fact, according to the 2021 results compiled by Domo, a lot DOES happen in a digital minute.

These are some pretty big numbers.

For instance, in the next 60 seconds:

People watch 694K hours of videos on YouTube
Twitter users post 575k tweets
Slack users send 148k messages
Users stream 452k hours of video on Netflix
Google conducts 5.7M searches
12M people send an iMessage
6M people shop online
Users send 2M SnapChats
People watch 167M videos on TikTok

The list goes on and on but there is one thing in common.

All of these services (and more!) are powered by APIs.

Why APIs?

Whether or not you are creating your own APIs you are consuming and using APIs. Everything runs on APIs.

APIs enable the Digital Ecosystem

So instead of asking Why APIs? a better question might be Why API Management and Governance?

API Management and governance have become a crucial part of the API Economy and the strategy and priories of businesses and enterprises around the world.

But let's take a look at the world without them.

In a world without API Governance, we have:

No Central Governance over Design and Development

The design for an API and integrations with other systems can have a huge impact on the direction and success of an API program.

No Full Lifecycle API Management

Full Lifecycle API Management covers everything from design and development of an API all the way through to retirement of an API.

No API Policy Enforcement

API Policies cover and enforce security and so much more

No Monetization of APIs

API Monetization is is not just referring to APIs that you sell or license. This is also talking about using APIs to leverage the business value of your other digital and physical products and services. It could also be controlling access or rate limiting APIs in order to be more secure or to protect resources from expensive traffic hits.

No Visibility over API Usage

How are APIs being used? (This goes for Public APIs / Internal APIs / Partner APIs / 3rd Party APIs)

Many Challenges for API Reuse
What APIs do we have?
What 3rd Party APIs are we using?
*Controlling access to APIs that are reused *
What about versioning? What version of an API is being reused?
The same goes for updates? Will APIs that are being reused be updated or patched when the original is updated?

What it looks like with an API Digital Ecosystem that is properly managed

Portfolio Consolidation of existing and overlapping services
Rapid integration API catalog with existing technology
Visibility to enable governing and managing full API lifecycle and API reuse
Scalable and flexible integration of new microservices components
Mitigating risks by enabling future modernization through APIs

To do this you have to have a solid plan that includes these important goals:

Creating an API-led Integration Strategy

APIs and Integrations are at the heart of Digital Transformation and an API-led integration strategy can ensure that you are equipped to succeed. A clear API strategy will allow you to transform your data and processes into digital capabilities that add value to your organization.

Securing Executive Backing

One of the key concepts behind a successful API Strategy is having executive backing. Identifying who all the stakeholders will be (both internal and external) is an important first step. It is important for everyone to realize their role, from executives, management, IT, Marketing, and Accounting... Everyone is a player in this game. Everyone needs to be invited to take ownership of the adoption, use of, and support of the API Program and its role in the Digital Transformation journey of your organization.

With stakeholders identified, executive backing and participation can remove a lot of possible friction points that might exist when making changes in an organization to support the adoption of an API program and strategy.

This is a critical step.

An API program and strategy needs to be executive-driven. Without good leadership and sufficient resources, API programs can become weak and fail.

Defining the Goals of your API Program

What are the goals and objectives of your API program? What do you see being accomplished through the successful implementation of your API Strategy?

Some common outcomes and goals that organizations might target include:

Securely managing access to data for customers, partners, and employees.
Open more opportunities for integrations with and from third parties.
Remove friction by making data more accessible through self-service channels.
Increase revenue by leveraging APIs and integrations with other products and services.
Empowering customers and employees through digital workflows that were not available before

Identifying Target Audiences

It doesn't matter if this is a public, a partner, or an internal API. It is important to be able to identify who the target audiences and users of your API program are going to be. In fact, according to a recent developer survey, 75% of developers reported working on internal APIs.

The target audience for a particular API program might be employees but it is important to remember that they are still your end-users and ultimately, the success or failure of your API program is going to have a lot to do with them. Don't take for granted that employees are going to love your internal API just because they work for your organization. Make the API developer experience a priority with a great developer portal and documentation.

Once you have identified your target audience, work with small groups of early adopters across your community. Find your API champions and leverage their desire and passion to use your APIs and adopt the API program to your advantage. Get feedback early and often throughout the program on many areas including:

The design and user experience
The terminology used in the APIs and documentation
Opportunities for improvement

Listen and be responsive to the concerns of your user base and let them know they have a voice. This will do wonders for the future adoption of your API Program and give the users a sense of ownership that you can leverage to organically grow your program.

Managing your APIs as Products

If your API is a product:

It will be designed with the customer in mind
It will be marketed to target customers
It will have a great user experience
You will make sure it works to build trust
It will have a great support community

Aligning Organization around Digital Strategy and Experience

As mentioned earlier, the participation and support of Executives can make a dramatic difference in the success of any Digital Strategy. There are often many adjustments that will need to be made to teams, resources, products, and marketing, to align around changes to the entire digital experience and an API-centric product focus. Executive stakeholders must be actively supportive of the teams the necessary financial and resource investments for the duration of the journey.

Some of the things that can be done to make the adoption of an API Program smoother are to:

Clearly articulate the vision and across organization
Be transparent with any necessary changes that are planned
Focus on organizational value gained by a successfully implemented program
Make sure everyone understands the value that they bring to the program
Encourage innovation and capture new ideas that can benefit adoption

It will probably be necessary to organizationally align teams by service. Some of the new roles you might see in the organization include

API Product Manager
API Developers/Architects
API Security Specialists

Securing your APIs

The importance of API Security and Cybersecurity goes far beyond your APIs themselves. As your API program grows, you will want to be sure that you have a comprehensive security strategy in-place. Your cybersecurity strategy should not be static but will live and grow with your organization, your APIs, and your digital strategy.

API Security starts with your API Gateway, making sure that it is properly configured and that you are taking advantage of all the security features in the product. You will also want to make sure your API Gateway can easily integrate with any other security products and applications you have in place with your API Management system.

Treat every API like it is a public API. Even if there are no plans to make it a public API, the security measures that you put in place need to be solid and secure in order to protect your applications and APIs. This will help to build trust with your employees and end-users while providing security and privacy for them AND their data.

About Brenton House

Brenton House is Vice President of Digital Evangelism at Software AG. As an API and Digital Transformation Evangelist and Strategist, he has connected enterprises with API solutions and microservices, to help drive innovation and overall business growth for many organizations.

In his 25+ years of experience, he has worked across many industries including broadcasting, advertising, retail, financial services, supply chain, transportation, technology, and publishing -- gaining a breadth of knowledge on all things APIs and Integrations. His diverse experience set and unique creative skill sets have enabled him to equip organizations in creating captivating and innovative products that delight users.

👉 Connect with Brenton House on LinkedIn! 👈

Check out some of our other resources to continue learning more about APIs and Integrations!

⭐    Software AG Blog ▪ https://blog.softwareag.com

⭐    API Knowledge Portal ▪ https://knowledge.softwareag.com

⭐    Software AG Tech Community ▪ https://techcommunity.softwareag.com/

🎬    Software AG YouTube Channel ▪ https://youtube.com/softwareag

🎬    Brenton House's YouTube Channel ▪ https://youtube.com/brentonhouse

🎬    API Shorts YouTube Channel ▪ https://youtube.com/apishorts

👇👇👇 FREE online API Maturity assessment here! 👇👇👇

https://www.softwareag.com/api-maturity

Top API Technology Trends for 2022

Brenton House — Wed, 29 Dec 2021 16:10:50 +0000

APIs are driving everything in 2022 and no one wants to be left behind. Software AG's Senior API Strategist, Brenton House, reveals the API Integration trends for 2022 and walks you through why these are important and how you can leverage these to ensure the success of the API portfolio at your organization.

Use these as a guide to see how Digital Transformation is driving your organization forward and what you need to do to ensure you are not left behind.

API Economy Growth
API-Led Modernization
API and Integration Experience
Open API Standards
API Best Practices
Industry-Specific Breakouts
API and Integration Automation
Adaptive API Management
Seamless Integration Solutions
API Cybersecurity
Composable APIs
- About Brenton House
- Check out some of our other resources to continue learning more about APIs and Integrations!

So where are API Integration trends heading in 2022?

API Economy Growth

At number 10, we have API Economy Growth.

The API Economy is taking the world by storm. When talking about the API Economy, we are not just referencing your ability to sell access to your APIs and data.

No, it's much more than this. It's about:

Revolutionizing how enterprises are organizing their teams, resources, and budgets.
The entire supply chain being powered by APIs
Ordering dinner and having it delivered to your home.
Providing a way to request an Uber ride and track it from beginning to end
Streaming movies and television shows to televisions, computers, and mobile phones around the world
Ordering fresh groceries and having them delivered from store to front porch

APIs on their own are not enough to drive this digital ecosystem. APIs are simply the enablers for and the gateway to the digital and physical products that you are already creating or plan on creating. APIs are what enable businesses to engage with consumers in the digital world. APIs are how your products are going to be viewed, purchased, consumed, and judged in this digital economy.

In order to compete in this very competitive API market, companies are adopting API First strategies. They are realizing that their APIs are a Product, and not an add-on to their existing products. These decisions to put budget and resources behind their API teams will allow them to succeed and win in 2022.

API-Led Modernization

At number 9 we have Modernization. Specifically, how APIs are powering the modernization of businesses across all verticals.

Mainframe and legacy systems can be a big dependency (and liability) for many organizations. We are seeing an increase in the number of companies that are using APIs and API Platforms to replace and extend the capabilities of their legacy systems.

API and Integration Experience

Coming in at number 8, we have the API and Integration Experience.

Everyone wants the experience with their API products to be magical. From APIs, API Documentation, API Developer Portals, and API Artifacts, a lot can be said about the user and developer experience across the entire API landscape.

The reason API Experience is on the Top 10 list is that along with the huge growth of APIs in the past few years, there has been a corresponding growth in expectations that users and developers have when they go to consume or integrate with an API product.

API Products and Portfolios need to include things like:

Being intuitive (a must-have!)
Well-documented APIs
Self-Service Developer Portal
Having a great onboarding experience (zero to API in 5 minutes)
Consistent and useful error messaging
Keep it simple (it has one job)
Don't be ugly (great UX and aesthetics)
Providing great logging and analytics
Including code samples and Postman scripts
Free-forever developer tier

A great developer and user experience for your APIs and integrations can give you an edge up over your competition and make a world of difference as to whether your digital and non-digital products are successful in this competitive market.

Open API Standards

At number 7 we have Open Standards for APIs and Integrations. In the past few years we have seen everything opening up and an increased adoption of open standards.

With the advancement of tools, technology, code, and no-code solutions, it's actually not that difficult to build an API these days. However, building APIs that are extensible, scalable, actually use best practices, and properly implement open standards can be a much more difficult feat.

RESTful APIs and open standards such as SOAP, Swagger, OpenAPI, JSON Schema, AsyncAPI, and GraphQL have been around for a while but we are seeing substantial growth in the community around the development of these standards and the participation from businesses and individuals in keeping these standards up-to-date with new features and improved documentation.

My recommendation would be to get involved with the groups that support these standards and participate in the process of growing the API community. If you are consuming and using these standards, (and I am sure you are), keep up-to-date with the changes to ensure you are producing and integrating with APIs in the best possible (and securest) way.

Take a look at some of the Open Standard communities that have been growing in the past year:

API Best Practices

Closely related to Open API Standards, we have API Best Practices coming in at number 6.

While there have always been Best Practices of some sort around the use of APIs, Integrations, and Microservices, it has been kind of hit-and-miss with what you could find and where you might find it. Often best practices might have conflicting messages or be so vague as to lead to branches of differing micro best practices.

Although RESTful APIs are solidifying their position as the current standard for APIs, we are also seeing an increase in the use of GraphQL, gRPC, and others. This has driven an increased need for formalized Best Practices around, not only covering what technology and standards to use, but how to do it in the best possible way so as to reduce the amount of future rework involved.

Best Practices include many API topics including (but not limited to):

API Design
API Security
API Integrations
API Transformations
Logging and Tracing
Code and Design Linting
Error Handling
Monetization
Onboarding
Versioning
Observation
Analytics
Documentation
Testing / Audits
Pagination / Bulk Data Handling
Eventing - WebHooks / Polling / Web Sockets
Scalability
And many more!

Industry-Specific Breakouts

At number 5 we are seeing an increase in the push for industry vertical-specific ecosystems around APIs and integrations.

Take Open Banking as an easy example of this. If you are in the financial industry (especially if you are in a geographical region that has government regulations around this), you have been aware of the changes both in standards and government regulations that have shaped how financial and banking APIs integrate with one another.

The healthcare industry is also seeing similar growth with the development and implementation of FHIR (Fast Healthcare Interoperability Resources) and other healthcare standards.

Expect to see a continuation of growth in some of these existing verticals as well as spikes and new growth in other industries.

Keep a watchful eye on Government, Manufacturing, Transportation/Logistics, Retail, Insurance, Supply chain, Telecom, and some others.

API and Integration Automation

At number 4 we have API Automation

I am a huge fan of automation and am actually excited to see the increase in API Automation adoption.

This goes beyond some of the automation that we have seen in previous years:

Automated API integration tests
Automated code unit tests
Automated publishing
Automated security checks.

GitHub has recently announced a new development tool called GitHub CoPilot. GitHub Copilot is an artificial intelligence tool developed by GitHub and OpenAI to assist users by auto-completing code. Now there has been a lot of feedback on this (both good and bad) but the point is things are changing. The goal of automation is not to replace workers but to allow workers to focus on more important tasks.

Keep an eye out for an increase in:

Automation for API design with various no-code solutions
Automation with API Integrations
Automation in API creation
Automation for API Management and Governance
Advancements in automation for API Security

Adaptive API Management

At number 3 we have Adaptive API Management

Managing the entire API Lifecycle can be challenging. Every organization is different and often the needs and requirements can be quite complex. Enterprises need to adapt quickly to changes in the market, changes in government regulations, changes in technology, and even changes in how (and where) people work.

New APIs are created every day and people need API Management that can adapt as well. Whether you are adapting to new API policy requirements, new API security threats, new API integration requirements, or new API consumer or partner opportunities, the need for an Adaptive API Management system is growing every day.

Because of issues like these, 2022 will see the continued growth of Adaptive API Management systems like webMethods which provides a robust and holistic approach to API Management. Some organizations need on-prem solutions. Others want to use cloud-based SaaS solutions. But a growing number will need something in-between with a mix of both.

Seamless Integration Solutions

At number 2 we have Seamless Integrations

An API without any integrations is like a car without fuel or power. It's may look pretty but it is not very functional.

Not only do APIs need to accept integrations and integrate with other APIs but there can also be complex requirements for chaining and transforming the incoming and outgoing data across these integrations.

APIs need to be able to easily integrate with anything, anywhere. 2022 will see the need for seamless API integrations that grow and scale even further with solid and proven integration tools standing out from the crowd because of their smooth and seamless handling of integration processes, both on-premise and in the cloud. Because of this increased demand for secure integrations with other APIs and systems, organizations want and need products that can remove the friction from their integration experience.

API Cybersecurity

At number 1 we have API Security and Cybersecurity

As long as there have been APIs, there have been hackers who are searching for vulnerabilities in those APIs. API Security and Cybersecurity is of critical importance for EVERY organization. Especially now. NOBODY wants to be in the headlines for all the wrong reasons.

Earlier, Gartner had predicted that by 2022, API abuses will move from infrequent to the most-frequent attack vector. The growth in not only the number of APIs but the exponential increase in API usage has made this prediction all the more impactful on businesses around the world.

According to a more recent Gartner CIO and Technical Executive survey, cyber and information security are at the top of the list for planned investments in 2022. This is not surprising as business leaders are feeling the pressure to put budget and resources behind cybersecurity to protect their APIs, data, customers, and the reputation of their companies.

You may have heard the phrase "Shift Left, Shield Right".

"Shift Left" is referring to is shifting your security focus to the beginning of the API Lifecycle process and to integrate it into the design, development, and every other step of the API Lifecycle all the way to the retirement of an API.

"Shield Right" is talking about the emphasis on continuing to protect your APIs at runtime and beyond. Doing this will allow you to provide a defense against unknown attacks.

Closely related to API Cybersecurity is the topic of encryption and privacy. Because of the close relation to security, they are included in this topic. Organizations are increasing their understanding and proper implementation of encryption to protect their data. Everything from storage and transmission of data requires a critical security eye when planning and implementing DevOps security. Privacy is also directly related to this as API Cybersecurity is an essential key to securing the privacy of users and employees. Not only does data need to be secured but sometimes the best decision is not to store the data at all. There are a lot of government regulations surrounding privacy in certain parts of the world but security and privacy requirements can also drive a strategy that reduces unnecessary data to protect both consumers and enterprises alike.

With the rising importance of API Cybersecurity, it is critical for everyone to understand what API Cybersecurity is, what is at risk, and how to protect and defend your APIs and other systems from attacks.

Check out this series of short videos to learn more about API Cybersecurity.

Composable APIs

As a bonus item for the list, keep a close watch on composable APIs. While composable architecture has been around for a while, the term is getting some extra attention lately and you will start to see more enterprises that may forego building part or all of an API and instead compose new APIs together from existing APIs (both internal and external). These new APIs will integrate with other APIs to add features instead of internally building new APIs or using existing SaaS services.

Composable APIs have the potential to give organizations the opportunity to reap the benefits from both the flexibility of a custom-built API and the seamlessness of a SaaS API subscription or service. Consumable APIs are heavily powered by the no-code SaaS and on-premise API integration solutions that exist today, such as Software AG's webMethods.io.

About Brenton House

Connect with Brenton House on LinkedIn!

Check out some of our other resources to continue learning more about APIs and Integrations!

👇👇👇 FREE online API Maturity assessment here! 👇👇👇

https://www.softwareag.com/api-maturity

API Security Explained! API Cybersecurity 101

Brenton House — Wed, 03 Nov 2021 16:15:31 +0000

So you think your APIs are secure?

You might want to take another look at your security.

APIs are everywhere and API Security is of the utmost importance for every organization. According to a recent Gartner CIO and Technical Executive survey, Cyber and Information security are at the top of the list for planned investments in 2022.

As someone who has spent my entire career in the world of APIs and Internet applications, I have seen first-hand the vulnerabilities that can exist with APIs.

So let's start with the basics.

What is API Security?

The simple answer is that it is about applying and managing security for your APIs but we all know, there is nothing simple about API Security.

In 1983, there was a movie called War Games that was released to theaters. You may have never heard of the movie but it was about a boy, David, played by Matthew Broderick, who hacks into NORAD's Military Computer System and accidentally ALMOST starts World War III. The movie got the attention of the most powerful man in the world, at that time.

According to journalist Fred Kaplan, After seeing a special screening of the movie "War Games", then-President Ronald Reagan asked the US Military Joint Chief of Staff if something like this could really happen. He asked "Could someone just break into our most sensitive computers?" A week later, the General response was:
"The problem is much worse than you think."

From that moment on, U.S. Cybersecurity and defense policy would never be the same.

Fast forward almost 40 years and everyone with a smartphone has a computer more powerful than any supercomputer that existed at that time. YouTube is now full of free videos and training on how to code and become a serious developer (or a hacker). What that means is that almost anyone, from anywhere, in any country, could be trying to get into your APIs and systems TODAY. Everyone needs to be educated and prepared to defend against API attacks; malicious or not.

What most don't understand is that API security starts with humans not computers.

If someone puts their password on sticky note attached to their monitor, it doesn't matter how many security checks you do, how much security code you have in place, or what different security products you have installed.

There are, however, a lot of things that you can do to protect yourself and minimize damage from this and other forms of social hacking. We will be covering this in upcoming articles of our API Cybersecurity series.

API Gateway

There are some key weapons that you can arm yourself to defend your systems from attacks by API Hackers and intruders. The core to your API security is going to be an API Gateway. An API Gateway can provide protection against a lot of things including Denial of Service attacks. They can also provide API Monitoring, Logging, and API Rate Limiting. They can restrict traffic based on IP addresses and other metadata, handle security token validation, and much more. The API Gateway makes it easy to create, maintain, monitor, and secure your APIs.

Web Application Firewalls (WAF)

The Web Application Firewalls (or WAF) stands between the public traffic and your API Gateway or application. A WAF can give you some additional protection against things like bots by using security rules, machine learning, and sometimes, artificial intelligence. They can provide malicious bot detection, identify attack signatures, provide additional IP Intelligence. A WAF can block bad traffic before it even reaches your Gateway.

Standalone Security Products

Then there are also stand-alone security products. These products support features that can be broken down into categories such as realtime protection, static code and vulnerability scanning, build-time checking, and security fuzzing.

Many of the security products in the market will support features in some or all of these categories.

Security in Code

Last of all, we have security that is implemented internal to the API or applications themselves. I am not going to go into this very much on this article but I will simply point out the resources required to ensure that all the security is properly implemented in your API code can be difficult to apply consistently across your entire API Portfolio.

API Security Precautions

With any security feature or product, it is important to remember that security is a moving target. You want to know that the product (or products) that you use will stay up-to-date in protecting you against the latest vulnerabilities.

But doesn't an API Gateway implement "Security as a Feature"? Yes. And it is a critical part of your API Management security strategy. API Gateways integrate with and work well with standalone API security products and Web Application Firewalls to provide solid and comprehensive protection for your APIs. Leaving out the core part of your API security strategy, such as an API Gateway, a component that probably knows more about your APIs and the context of your traffic than any other system, is a really bad idea.

If you only focus is on using Web Application Firewalls or external security products and you ignore (or mis-configure) the protection provided by your API Gateway security, you could be leaving yourself wide-open for an attack.

Don't leave yourself vulnerable!

API Security Black Box?

All of this only reinforces the fact that there is not a one-size-fits-all solution for API Security. You can't just buy an "API security black box" from Best Buy, plug it in, and suddenly everything is protected.

To implement a proper API Security Solution, it is important to understand your APIs, the 3rd-Party APIs you use, and the functionality and value your APIs are adding to your organization. This will help you better grasp how API Security ties into integrations with your partners and users. API Security is still one area that will require you to spend some time and resources to ensure it is implemented, (and CONTINUES to be implemented) correctly.

Security for API Integrations

When you are looking at your API ecosystem, don't forget about API Integrations and the 3rd Party APIs that you will be integrating with. If these 3rd Party APIS, or the integrations themselves are insecure, your data, internal systems, and APIs could be compromised. Using a solid API Integration solution (like Software AG's webMethods.io) with a proven track record can not only protect your API Integrations but work seamlessly with your API Gateway platform.

API Cybersecurity 101

To better equip organizations and individuals better protect themselves and their APIs, We've created a new series called API Cybersecurity 101. The purpose of this series of videos and blog posts is to educate and equip everyone from developers to executives with the resources you need to shield and protect your APIs. You can checkout our API Cybersecurity video series on YouTube on the API Shorts channel: https://youtube.com/apishorts

About Brenton House

Check out some of our other resources to continue learning more about APIs and Integrations!

👇👇👇 FREE online API Maturity assessment here! 👇👇👇

https://www.softwareag.com/api-maturity

10 Keys to WINNING with an Awesome API Developer Experience!

Brenton House — Tue, 21 Sep 2021 13:47:03 +0000

Let's face it. Not every API Platform works well.

But why is that?

What is the difference between an API Platform that is a smashing hit and one that is not?

Well, there are a few very important factors like making sure it works and that has the features that users of the platform need and/or want.

Sometimes, it is because they are missing features.

Other times, it is because the features that they have, don't work.

But often the API Developer Experience itself gets forgotten. Most realize that it is something important and necessary but when forced to prioritize it in the long list of backlog items, it often gets bumped down to the bottom.

If the developer experience for an API Platform is horrible, users might walk away from your platform instead of being hooked.

What can we do about it?

What exactly does it take for developers and architects to LOVE your API Platform?

What does it take to turn the USERS of your API Platform into CHAMPIONS of your API Platform?

I am going to show you the 10 things you need to do to win over the users of your API Platform and make them (and you!) successful!

But first, let's quickly define a couple of things.

First.

What is an API?

Basically, it is non-human systems that talk to each other in an agreed upon way! Most often, people are talking about Web APIs, include things like REST, GraphQL, gRPC, SOAP, etc.

What is an API Developer Portal?

An API Developer Portal can look different depending on the products that are used but most often it is a website that can be used to manage APIs, view documentation, discover APIs, configure things security, and more!

Okay. Let's jump into it.

10 Keys to WINNING with an Awesome API Developer Experience!

1. Your API Platform needs to be intuitive.

Everything from your API endpoints, API Authentication, API Developer Portal, API Documentation, API code examples.

Everything!

For a lot of APIs like REST, gRPC, GraphQL, and other types of APIs, we have some standards.

Now some of these "standards" a little loosey-goosey BUT where there aren't solid guidelines, there are usually some really good published best practices available.

Follow these.

Don't try to come up with your own custom system for APIs or API Portals.

Just Don't.

Users will come into this with certain expectations based on industry standards.

Take advantage of things like OpenAPI, OAuth, AsyncAPI, and Swagger to help you in that process.

2. Your API Platform needs to be well-documented.

How well documented probably depends somewhat on how complex your API Platform is.

This also goes hand-in-hand with the number 1 rule about being intuitive. The more intuitive your API Platform is, the less reliant on your documentation developers will be.

There are things you can add to your documentation such as making it interactive. While this might take some additional time in setting up the initial version of this documentation, it can provide a more customized and rich experience for your users.

Another important part of documentation is the changelog.

It is very important to document what has changed between versions of your API Platform. Don't just add a bullet point, if possible, but include how these API calls are different or how a task in the API Platform will now be performed.

3. You need to have a self-service API Developer Portal of some sort.

An API Developer Portal is often where you will have the developers go to do things like managing API Keys, creating proxies for APIs, and much, much more.

If you are using an API Management system, you probably already have some sort of an API Developer Portal for the APIs that you are managing in that system but that doesn't mean that there is nothing that you need to do. Most portals include the ability to customize the portal to fit the needs of your organization.

If this is the solution that you are using, you will want to make sure that you are presenting things in the best possible way for the users of this portal.

If you are using your own custom solution for an API Developer Portal, a lot of the same rules apply. If this solution is built in-house, you might have more flexibility with what you can change but changes always come with a cost that includes time and resources.

4. Having an awesome Onboarding Experience.

You know what they say about first impressions, right?

Well, it's true.

This first experience that your users have with your API Platform could make or break your future relationship with this user and affect your bottom line.

Ideally, you want your users to be able to go from Zero to Api in ABOUT 5 minutes.

A user should be able to:

Create an account
Log in
Create an API key or other authentication token
Connect to your API
and challenge completed!

5 minutes.

Now, I know not every API or product is the same

and some are going to be a lot more complicated but in general, let's aim for 5 minutes.

I am also not saying that is going to be some masterpiece ready to go into production.

It is something simple that gives the developer a good feel for your platform and builds a trust level with you and your products.

If you are taking substantially more time than this, look for your bottlenecks and tackle them to reduce any friction that the user might have when onboarding.

If you don't know what your user's Time to First API is, find that out now!

5. Must have Great Errors.

I am not saying that your API should be buggy and have lots of errors, but developers are going to try all sorts of things with your API.

Things you may not have thought of or maybe things that you have thought of and don't want them to be able to do.

When this happens, you will need to provide error responses that are consistent and well-documented.

There are several different patterns and best practices out there in regards to API errors but be sure you are consistent across your API endpoints. If you are using something like error codes, go ahead and put a url in the error response that gives the user more context about that error.

6. You need to keep things simple

This applies to your APIs and to your API Developer Portal.

Don't over complicate things. Focus on one thing at a time and do it really well.

If there is only one possible thing that the user can do given their current state in your API Developer Portal, then remove or hide the other options. Don't confuse them but instead guide them to make sure that they are successful (and happy) users!

Also, when you are focusing on that one thing, be sure it is something that is actually solving a problem for the user.

Don't add a bunch of unnecessary steps or tasks in a process flow as this will just frustrate your end users.

7. Don't be ugly.

There I said it but it's true.

Ugly designs can slow people down.

This is also directly related to rule number one: API Platforms must be Intuitive. Really poor design of API Developer Portals, API Documentation, and API Endpoints can cause frustration for users.

Your API Developer Portal or documentation might be ugly because of something as simple as you are using a really bad color palette.

It could also be that you are trying to cram to much information into one screen.

It could also be that you don't understand how the users want to use your portal.

Take some time to learn more about your users and good design best practices.

But... Ugliness is not limited to your API Developer Portal or API Documentation.

It could also be your APIs themselves.

What do I mean by that?

Well, I've seen some pretty horrendous naming patterns for endpoints and parameters. It may seem like a small thing but you might add some love to your APIs by cleaning them up before publishing.

8. Show me the code!

That's right. Developers who use your APIs want to see some code examples for using your APIs.

There are several ways to do this.

Some include this option in the documentation itself but others will incorporate this into the API Developer Portal where the code can be customized to match the specific needs and configuration of that user.

Either way, you need to include code for a variety of the most commonly used API Client languages.

Another huge thing related to this is Postman scripts.

If you don't know what Postman is, it is THE original (and best) API Client / Testing / Mocking / Everything tool for consuming APIs.

PLEASE include a Postman collection for your APIs.

Use things like Postman environment variables to reference configurable things like API keys, endpoints, and such.

And for bonus points, generate some simple API tests for your calls.

This will tell the user what to expect when they make successful (and unsuccessful) API calls to your endpoints.

9. API Logging and Analytics.

You may not normally think of logging and analytics as something that is related to Developer User Experience but let me show you how it is.

If you have good logging that is available in a standardized way, a developer will now have access to one more resource that could save YOU time and resources but also possibly get THE USER to a resolved state much quicker.

Related to this is Analytics.

Some analytics might be available to a user such as number of calls.
(especially when rate limits are involved),

But I am talking about some of the analytics that they might never see.

So if the user can't see this, how does this benefit Developer User Experience?

If you were to thoroughly track what APIs endpoints and methods are being called,

If you were to thoroughly track what features were being used in your Developer API Portal,

If you were to thoroughly track what documentation pages were used most often and be able to correlate that to features in your APIs,

You would then be in the position to know where there might be friction points.

Where there might be opportunities for feature enhancements.

You will be able to see what's hot (and what's not)!

Think of it as the developer's journey through your product.

Use this data to give your developers the best possible user experience with your APIs, your Developer API Portals, and your API documentation.

10. Free Forever Developer Tier for your API Platform.

I cannot emphasize enough how important this is for continuing user satisfaction and relationships with your customer!

If your API is attractive to developers, there is a good chance that they are going to try it out before their boss tells them that they need to run an official evaluation of your product.

It might be in a hack-a-thon, side project, or just maybe just because they are curious.

Either way, developers will often save this off to have working examples of connecting to your API.

As a developer, you never know when you will need it...

But if their boss tells them to evaluate your product and it has been over 30 or 60 days and your product's trial has expired, this is going to leave a sour taste in the mouth of the developer or architect.

Sure, they can probably get on the phone, call your support department, and get an extension to their trial, but let's face it.

*Nobody wants to have to do that. *

I don't care HOW good your support department is.

Do yourself a huge favor and create a limited tier of your product that is free forever.

It doesn't have to have every feature and it can be rate limited but at least your user's code will most likely still work when they go to try it later.

Conclusion

There is a lot to API Developer Experience and this really only scratches the surface.

Chances are you are already working on (or have successfully accomplished) many of these keys to API Developer Experience but don't forget about them.

Take the time as a team to review these and make sure that your APIs (both old and new) as well as your API Developer Portal and documentation is equipping developers and other users to be successful!

Feel free to connect with me on LinkedIn and ask me any question or share your experiences with APIs! I would LOVE to hear them!

https://linkedin.com/in/brentonhouse

About Brenton House

Check out some of our other resources to continue learning more about APIs and Integrations!

👇👇👇 FREE online API Maturity assessment here! 👇👇👇

https://www.softwareag.com/api-maturity

😢 Saying Goodbye to Axway Amplify Titanium

Brenton House — Fri, 07 May 2021 18:39:42 +0000

🪦 RIP Axway Amplify Titanium (2010 - 2022)

"Everything has to come to an end, sometime."

- L. Frank Baum, The Marvelous Land of Oz

🎬 See the latest videos from Brenton House on API Shorts YouTube channel!

"Can't wait for more!"
★★★★★ - Cordelia Wedderburn

"Cery cool!"
★★★★★ - Rolando Rentas

"Best overview of API security I've seen! Need more videos like this"
★★★★★ - L Colbert

I first met Titanium long ago,

before she was married to Axway...

Back then she was known by her maiden name:

`Appcelerator`

It was over 10 years ago and she was so full of life!

But first, a little background...

My name is

Brenton House

and I ❤️ APIs

There. I said it.

Wait! I thought this was about Titanium and mobile??

It is. But to understand mobile

(I mean REALLY understand it),

you have to understand APIs.

I had invested my career in APIs.

Designing, Developing, Architecting, and Evangelizing APIs.

I loved seeing the web being created and taking shape.

Communication standards and APIs of various shapes, colors, and sizes appeared (and disappeared).

But mobile was going to change everything.

I realized that mobile apps were going to make the API market EXPLODE! There was suddenly going to be a massive growth in the number of API consumers in the world!

I never left the API world but did realize that expanding my horizons to include the mobile app economy was essential to being successful with APIs and Integrations in the future.

But... I am getting ahead of myself

Let me back up a bit...

The year is 1989

Tim Berners-Lee, a British scientist, invented the World Wide Web (WWW) in 1989, while working at CERN.

Wait... let's not go back that far!

The year is 2007

although it feels like it was just yesterday.

The mobile development market was suddenly revolutionized with the introduction of the first iPhone by Apple.

The first Android phone also released a short time after that and it became clear that developers were either going to have to become experts in both Objective-C for iPhone and Java for Android or some other solution was going to have to appear.

PhoneGap and similar hybrid "web" mobile apps appeared but most people realized that they were never going to be a serious solution due to the lack of features and performance issues that were inherent to non-native mobile apps.

The year is 2011

I was introduced to Appcelerator Titanium Mobile.

She had already hit her 1.0 version milestone and had quite an active development community.

I still remember the first time I saw her.

Write once.  Run Everywhere.

With Appcelerator Titanium, I could write JavaScript code and it would create a native mobile app using Objective-C and Java for the appropriate platforms.

WOW!!

Could it really be that easy??

With the introduction of the Appcelerator Alloy library for Titanium, the JavaScript features expanded to include an MVC framework with even more options for using JavaScript to access native iOS and Android features! Titanium Alloy hit version 1.0 and everything seemed like it was going so well!

The year is 2015

Facebook released a new product: React Native, a mobile JavaScript platform that seemed to have a similar set of features to Titanium.

Also in 2015, another JavaScript platform, NativeScript, was also released to the community.

The plans for Titanium Alloy 2.0 got pushed out and suddenly there was a lot more diversity (and competition) in the cross-platform native mobile market.

The year is 2016

Axway acquired Appcelerator and integrated it into the Axway Amplify Platform.

You may recognize some of the different variations used to reference the Titanium products over the next few months that followed!

Appcelerator Titanium
Appcelerator Titanium SDK
Appcelerator Titanium Alloy
Axway Titanium
Axway Titanium Mobile
Axway Appcelerator Titanium
Axway Appcelerator Titanium SDK
Axway Appcelerator Titanium Alloy
Axway Amplify Appcelerator Titanium
Axway Amplify Appcelerator Titanium SDK
Axway Amplify Appcelerator Titanium Alloy
Axway Amplify Titanium Alloy
Axway Amplify Titanium Mobile
Axway Amplify Titanium

The year is 2018

Given my ❤️❤️❤️ for APIs and Integrations -- combined with my personal experience using Axway Amplify Titanium, I joined Axway as an API Evangelist!

Over the next couple of years, 
I was able to get creative with a lot
of fun blog posts and YouTube videos!

Who can forget, `Breaking the Build` and important topics like `Tabs vs. Spaces`? 🤣

With `API Cookery` we covered API Management and Integrations!

Axway Amplify Titanium features continued to be added to the SDK over the next couple of years!

Although Axway Titanium Alloy v2.0 never materialized, I did end up forking Titanium Alloy v1 to add in a bunch of v2 type features to make Titanium easier to use with APIs and Node.js.

It kinda spun off into its own open-source product Titanium Turbo.

It was super cool and I was able to use Titanium Turbo to create native mobile apps faster than I could ever imagine doing before!

It also made integrating with APIs a snap (which was very important, given my ❤️ for APIs )

You can see an example of using Titanium Turbo in a complete API and Mobile App solution for managing the return of employees to the office, that we open-sourced last year!

// Detect dark theme var iframe = document.getElementById('tweet-1321095757852823554-586'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1321095757852823554&theme=dark" }

(SPOILERS: Unfortunately, given the recent news, Titanium Turbo will probably die a nice, quiet open-source death with very little fanfare...)

The year is now 2021

We have now caught up to present day but unfortunately, it also means that we've reached the end of our story.

A few weeks ago, Axway announced the End-of-Life for Axway Amplify Titanium.

It's sad saying goodbye!

Although Axway will be shutting things down in March 2022, because it is an open-source product, forks of it will still live on in the community!

There are very few products I have been able to closely observe from cradle to grave. It has been a pleasure to work with such an innovative and active community!

API Integrations are sometimes difficult for people to wrap their heads around and Titanium made it easy to be able to see the power of APIs in the palm of their hands!

Titanium had a great run and 
I am grateful there are so many 
in the Titanium community, 
both past and present, 
that I can call great friends!

On a personal note, I have decided that the timing was right for me to begin a new chapter in my career and I will be leaving Axway this week. I have thoroughly enjoyed my time at Axway and have worked with some truly amazing and talented people!

My love for APIs and Integrations has only grown stronger over the past few years and I am going to continue following my passion for evangelizing them to the community!

Connect with me on LinkedIn or on Twitter as I continue to share what I learn about this crazy digital world we integrate with everyday!

Keep Coding Strong!!

🥇 What exactly is API First?

Brenton House — Wed, 17 Mar 2021 16:18:40 +0000

API First explained!

*What is API First? How can I leverage API First to add business value to my organization? Is API First the same as API Design First? *

There is a lot of confusion around "What is API First", how is it different than "API First Design", and how all this fits into the Full API Lifecycle Management process. Today, I caught up with Brian Otten, an API expert, who has a proven track record for helping enterprises on their API journey to success!

↑ Watch video on YouTube ↑

What is API First?

To think about API First, you really have to start thinking about your business. How are you reimagining your business? If you have a new business, what is that business going to look like? API First is very much linked to strategy and how you want to merge your business model with the emerging technology model. For most companies, you are going to think of that in terms of creating a digital platform where you can take your world-class products and services and make them consumable. You might also think about how you want to extend your products out so that you can make them all easier to work with.

This is where API First comes in.

API First takes the view of your business as capabilities, with products and services that you are going to deliver. Using API First, you would then enable you to imagine those as a set of API Products or APIs working together to get the data, provide the access, and make it secure. This is the API First way. Instead of starting by building the applications or looking for backend systems of record, you start with API First. This can be a big strategic move for an organization.

Is API First the same as API Design First?

Short answer is no. API Design First is an essential part of the operations to create the digital products and APIs but API First takes a step back and looks at that reimagined view of your business as a set of interoperable APIs. You are asking questions like:

What is the value proposition of an API?
What is the business model behind the product we are going to create?

When you then go to use API Design First to create the APIs during the API First process, you can leverage the research and strategy from previous steps by asking:

How did we imagine this solution?
How do we solve this business problem?
How do we get real business outcomes from this by having a good design?

How does API First work with the Full API Lifecycle Management process?

API First feeds and powers the Full API Lifecycle Management process. The stages of an API's Lifecycle can include things such as:

Designing and Planning your APIs
Creating your APIs
Securing your APIs
Documenting your APIs
Testing your APIs
Versioning your APIs
Deploying or Publishing your APIs
Monetizing your APIs
Observing and Managing your APIs
Scaling your APIs
Making your APIs Discoverable
Retiring (or Sunsetting) your APIs

Throughout all the Full API Lifecycle Management process, you will view your APIs through the lens of your business strategy. API as a Product will allow every level of your organization to make API decisions knowing how this product fits into your enterprise and how it adds business value. Knowing the business value added by your APIs can make a world of difference to the success of your API Platform.

API First, DevOps, Business Ops, Product Ops and more!

Watch the full interview with API Expert, Brian Otten, to hear even more about how API First enables and empowers your organization through DevOps, Business Ops, Product Ops, and more!

Stay informed about Best Practices for APIs and Digital Transformation

Subscribe to API Cookery on YouTube to stay up-to-date with the ever-changing world of APIs and Digital Transformation!

About Brenton House

Check out some of our other resources to continue learning more about APIs and Integrations!

👇👇👇 FREE online API Maturity assessment here! 👇👇👇

https://www.softwareag.com/api-maturity

🕵️ 5 Things to do NOW for Apple App Tracking Transparency API

Brenton House — Tue, 23 Feb 2021 22:31:30 +0000

Here are the five things you need to do right now to be prepared for Apple's new App Tracking Transparency API!

↑ Watch video on YouTube ↑

In the past few weeks and months, there has been a lot of the talk and controversy around Apple's new Tracking Transparency API. The discussions center around access to the Identifier for Advertisers or the IDFA. The IDFA is an ID that allows apps and APIs to uniquely identify a user across multiple apps and websites.

The IDFA is most commonly used by advertisers such as Facebook but it is also used by some apps for fraud detection and other non-advertising purposes.

The IDFA is why you will be looking at a product on one website or app and suddenly you see an ad for the same product in a completely different app or website. This ID allows advertisers to keep track of who you are and, when combined with additional information collected across different apps, can give a very detailed profile about a user without them ever knowing.

Apple has decided to change how the API for the IDFA works. It's not going away, but will now require apps to prompt users to ask them if it is OK to get access to the IDFA for tracking purposes.

Apple App Tracking Transparency API

Here are the five things you need to do right now as an App or API publisher to be prepared for Apple's new App Tracking Transparency API.

1️⃣ If you want access to IDFA, you have to request it

If the user says NO, you are not going to be able to access the IDFA.

Although Apple introduced this API in 2020, they have not been actively enforcing it. But with the upcoming iOS release, Apple is requiring the permission prompt and will be working to enforce this API and their policies using automated and manual processes.

2️⃣ Need to check your APIs and SDKs

You need to thoroughly check your APIs and SDKs to ensure that you prompt users for permission if you are using the IDFA. If your app (or an third-party app that uses your API), tries to use the IDFA without permission, you could be banned by Apple. A good percentage of users will probably decline permission for this and that could cause problems for you or your users if it breaks functionality.

3️⃣ Need to check your Third-Party APIs and SDKs

You may be thinking "I'm not using the IDFA so I am safe". While this may be partially true, you may not be directly accessing the IDFA in your apps or APIs but there is a pretty good possibility that the IDFA may be being used by third-party SDKs or APIs that you are dependent on. You will need to do a deep look at all third-party components for uses of the IDFA and that may not be an easy task, depending on the complexity and size of your mobile apps. If a third-party API or SDK is using the IDFA, you will need to contact them about an updated version of their API.

4️⃣ Look for Alternatives to IDFA

The tracking permission screen is kind of a scary prompt for users. Big Tech companies like Facebook, who are very depending on the IDFA and user information for their business, are creating explanation screens to try to soften the blow in an attempt to convince users to agree to allowing Facebook track them.

Due to the fact that a lot of users are not going to approve permissions to track combined with the complexity of other privacy regulations, means that API Publishers are going to be looking for new and creative ways to be able to track users without the IDFA -- but that will not be an easy process.

Apple is pushing publishers to use the Apple SkAdNetwork as an alternative to using the IDFA. The problem with this is that now you would be using a system where Apple owns the entire process and thus your data is controlled by them.

5️⃣ Get ready for Google changes

Google has an equivalent ID called the Google Play Services ID for Android or GPS ADID. Be on the lookout for upcoming changes to these APIs as well, because rumor has it, changes to these APIs will be coming soon.

Stay informed about the Apple Tracking Transparency APIs and upcoming changes so that you and your business will not be disrupted!

In addition, you can subscribe to API Cookery on YouTube to stay up-to-date with the ever-changing world of APIs and Digital Transformation!

About Brenton House

Check out some of our other resources to continue learning more about APIs and Integrations!

👇👇👇 FREE online API Maturity assessment here! 👇👇👇

https://www.softwareag.com/api-maturity

🛑 What are API Rate Limits?

Brenton House — Wed, 17 Feb 2021 16:51:11 +0000

API Rate Limiting is simply controlling how many requests, or calls, an API consumer can make to your API. You may have experienced something related as a consumer with errors about "Too many connections" or something similar when you are visiting a website or using an app.

↑ Watch video on YouTube ↑

What is an API Consumer?

An API consumer could be a mobile app, a website, or even your doorbell or thermostat! Anything that makes a call to an API to get data is an API consumer. These are made via API Requests.

🎬 Check out more API videos here! ( BYOP - Bring your own 🍿 )

What is an API Request?

An API request (or call) is where one of these consumers, say your thermostat, requests information from "the cloud" (or servers on the internet).

Say your thermostat wants to find out what the current weather conditions are so that it can display those for you.

That would be an API request.

The largest number of API requests, by far, come from mobile apps. A single mobile app might make between 10-20 API requests, just by you opening an app and logging in!

How are API Rate Limits typically set?

API Rate limits are typically setup to limit the number of requests either by:

per second
per minute
per hour
per day (or 24 hour period)
per month

An API is not limited to picking just one of these. You could have one API Rate limit for per-second and a different API Rate Limit per-hour. One or more API Rate Limits can be active at the same time.

API Rate Limiting might even be implemented differently depending on if you are authenticated or not. Authenticated API users (or API consumers that have included their credentials in the API Call) might be allowed more requests than users who are anonymous.

Do I need to implement API Rate Limiting?

Most likely, Yes. But it is important to understand the reasons why you might need them. If you are going to measure the success (or failure) of rate limits, you have to have a clear and defined purpose.

What are reasons typically given for needing API Rate Limits:

Here are some of the reasons you might hear but not every one of these problems is best solved by API Rate Limits!

Protect your APIs from Distributed Denial of Service Attacks or DDoS.

While these attacks are a very real threat and can take down your API (which is a bad thing), API Rate limiting is probably not the right solution for blocking these attacks. There are other, and more robust, solutions for protecting your APIs from DDoS that should be looked at first.

Limit your backend expenses and costs

This can be a very legitimate reason for implementing API Rate Limiting. Let's go back to the thermostat example. Say there is a line of thermostats that go bonkers and go into some loop where they are calling your weather API over and over. While this might not take down your API, it could cost you a pretty penny because you are the one that has to pay for all the backend servers and services that make that weather API work! By limiting the calls per consumer, you could protect your resources and money!

Work around hardware limitations

Getting a lot of API calls could mean that your backend servers can't keep up properly. This could lead to bottlenecks and the equivalent of driving on the highway during rush hour traffic. It could slow everyone down as requests are queued up. Slow API calls could mean things like really slow web pages and really unhappy users.

What are my options for implementing API Rate Limits?

There are a few different ways of handling API Rate Limits:

Hard Stop: This means an API Consumer will get an Error 429 when they call your API, if they are over their limit.
Soft Stop: In this case, you might have a grace period where calls can continue to be made for a short period of time after the limit is reached.
Throttled Stop: You might just want to enforce a slow-down on calls made over the limit. This way users can continue to make calls but they will just be slower because they are over the limit.
Billable Stop: Here you might just charge the API consumer for calls made over their limit. Obviously this would only work for authenticated API users but can be a valid solution.

💡 BONUS TIPS for API Rate Limits!

If you don't want your API Users to hate you, there are three things you need to do:

1️⃣ Don't be greedy

As we talked about earlier, there are several reasons for needing to implement API Rate Limits. Getting too greedy with your limits though, can keep users from being able to implement the solutions they need to help them win. You win when your users win so don't drive them to abandon your API for a competitor's API because you arbitrarily set your limits to low.

2️⃣ Be transparent and informative

Be transparent with users on how you implemented API Rate Limiting and what methods you choose to handle it when users go over their limit. You really want to make sure that you are up-front with your users if you are going to be charging them for overages.

Clearly document everything and educate your users, not only about your API Rate Limiting Policy, but also about steps they can take to avoid hitting those limits.

3️⃣ Let API consumers know what the status of their API Limits are in every call.

There are a couple of different ways to implement this but most APIs will add a header to the API response that tells the consumer how many calls they have left for this period of time and when the counter will reset.

This way API Consumers can make informed decisions about when (and how many) API calls to make.

About Brenton House

Check out some of our other resources to continue learning more about APIs and Integrations!

👇👇👇 FREE online API Maturity assessment here! 👇👇👇

https://www.softwareag.com/api-maturity

⭐ Top 10 API Trends for 2021 Digital Transformation

Brenton House — Thu, 11 Feb 2021 19:20:45 +0000

👉 NEW 2022 API Integration Trends HERE! 👈

https://brenton.house/top-10-api-integration-trends-for-2022-49b05f2ef299

API Integration Trends for 2021

APIs run the world and 2020 saw a huge increase in the dependency on API creation, management, and consumption. We will see this increase even more in 2021.

↑ Watch video on YouTube ↑

Why are API trends important to follow and understand?

Since almost every mobile app and website is powered by APIs, understanding these trends will equip you to make business decisions that will impact how competitive you can be in this ever changing world.

🎬 Check out more API Best Practice videos here! ( BYOP - Bring your own 🍿 )

Here are the Top 10 API Trends for 2021!

10. Growing Public Awareness of APIs

A global shift to remote work and online ordering has brought awareness of APIs to the masses. This will only grow as APIs are elevated to product status in enterprises.

9. Focus on API Design Standards

The increased development and adoption of APIs has made proper API design a critical step. Initiatives for standards such as OpenAPI and AsyncAPI will also continue to grow.

8. Streaming and Async APIs

Feature rich applications mean more content is being sent over APIs. Adoption of Streaming and Async APIs lowers bandwidth and costs by allowing data to be streamed to consumers on any platform.

7. API Developer Experience

This competitive API market means that APIs can no longer be haphazardly released. APIs must follow best practices and have great documentation and support to succeed today.

6. API Strategy and Maturity

A post-COVID world has forced enterprises to solidify their API strategy to reach an API maturity that allows them to succeed in a very competitive world.

5. Hybrid API Management

APIs do not live exclusively on-premise or in the cloud. Real-world APIs are a mixed bag and enterprises depend on proven Hybrid API Platforms to manage them properly.

4. Low-Code API Development

Developing APIs using Low-Code API platforms gives enterprises the flexibility to create and manage their APIs using a wider range of technical skill sets.

3. Measuring APIs with KPIs

Enterprises are now managing APIs as products. This requires defining the right KPIs and measuring them in order to communicate business value to stakeholders.

2. API Security and Governance

With API usage skyrocketing, they have become a target for hackers and thieves. Securing APIs has never been more important than it is right now.

1. API Privacy and Encryption

Privacy concerns have led to an increase in encrypted APIs (such as the Signal and Telegram apps) and a public outcry over APIs being used to track people and their private data.

About Brenton House

Check out some of our other resources to continue learning more about APIs and Integrations!

👇👇👇 FREE online API Maturity assessment here! 👇👇👇

https://www.softwareag.com/api-maturity

How to manage multiple environments from single project

Brenton House — Thu, 05 Nov 2020 15:39:50 +0000

If you are developing a mobile app or and API like we did with the Griffin App, there is a high likelihood you need to deploy these to different environments. You might have a production environment, development environment, or even more.

Coordinating the migration and deployment of these across mobile, local APIs, cloud APIs, and cloud databases can be challenging! You don't want to split your codebase into multiple projects because maintenance because a nightmare. So how do you manage the release environments for API or Mobile app from a single project?

Read more about how Axway built the Griffin App and API and provided a solution for assisting with the safe return to the office at Axway

APIs

For our projects, we use AMPLIFY API Builder to create APIs that we can deploy anywhere. The project can easily be built and tested locally and then deployed to an docker environment (AMPLIFY Runtime Services, in our case). The challenge is we needed to be able to deploy the same codebase to multiple environments. In order for this to work, we needed to design it with this in mind. With the API projects, there is not too much that has to be changed.

Put all API keys, API endpoints, etc. in an environment file (i.e. .env.prod)

API_BUILDER_APIKEY=123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ

Anywhere in your API you need to then reference these variables like this:

const apikey = process.env.API_BUILDER_APIKEY;

With API Builder, you can modify the default.js file to replace the hard-coded API key with a reference to the value from the environment file.

Change the package name in package.json based on your environment.

For Production environment, you might have:

{
    "name": "acme-api-production"
}

whereas your Development environment might have:

{
    "name": "acme-api-development"
}

Ideally, you would write a short npm script that would do the following when you switch environments:

package.json

{
    "scripts": {
        "switch":   "node ./scripts/switch-environment.js"
        "switch:dev": "npm run switch dev"
        "switch:prod": "npm run switch prod"
    }
}

and inside switch-environment.js, you would do the following:

Change name in package.json file
copy environment file (i.e. .env.prod -> .env)

Cloud Databases

Axway's MBaaS solution supports a production and development environment, out of the box, so in many ways this part is much easier. You simply need to take the keys for each environment and put them in the environment files we created above.

There is no built-in way to migrate data between environments but Leor Brenman has created a great script that can be used to move data. You can read all about it in his post about the Axway MBS Custom Object Data Migration Utility.

Mobile Apps

Changing environments within your AMPLIFY Titanium mobile app can be a bit more complex but it is the same general concept. There are several things that will need to be updated when changing environments:

App icon (optional)
tiapp.xml
- id
- name
- guid
- description (optional)
- publisher (optional)
- oauth info (endpoints/clientid/etc)
- api info (urls/keys/etc)
branding (optional)

I usually chose to change the App Icon so users can distinguish between the dev/prod apps that might be installed side-by-side on their device.

Like your API project, you will then have some npm scripts you can run to switch environments:

package.json

{
    "scripts": {
        "switch":   "node ./scripts/switch-environment.js"
        "switch:dev": "npm run switch dev"
        "switch:prod": "npm run switch prod"
    }
}

Because we are not reading from environment files for mobile projects, you will need to store your environment specific urls/api keys/etc in a json file which your script can then read and make the appropriate changes to your tiapp.xml file before building your project.

If you are going to completely white-label your mobile apps, there are other things you will need to change such as branding and colors but not all of that is necessary for a simple environment change.

Wrapping it up

Using and expanding upon these techniques can allow you to enable the flexibility you need to fit the unique requirements of your organization! There are also many other ways that teams can support multiple environments. Let us know in the comment section below how you and your team tackle these issues!

We have open-sourced the source code for our Griffin App and APIs! Using Axway AMPLIFY Platform to create solutions for real-world challenges!

About Brenton House
With 25 years of experience in the development world, Brenton House leads Developer Relations for Axway's API and mobile products, He has worked closely with many clients across various industries including broadcasting, advertising, retail, financial services, transportation, publishing, supply chain, and non-profits. Brenton's passion for everything API and mobile combined with his strategy and design experience, has enabled him to help developers create captivating products that inspire and delight audiences.

About Brenton House

With 25 years of experience in the development world, Brenton House leads Developer Relations for Axway's API and mobile products, He has worked closely with many clients across various industries including broadcasting, advertising, retail, financial services, transportation, publishing, supply chain, and non-profits. Brenton's passion for everything API and mobile combined with his strategy and design experience, has enabled him to help developers create captivating products that inspire and delight audiences.

Ask-a-Geek questions are answered by Brenton House, an API and Mobile geek who has been doing dev work for 25+ years.

How do I add the Star Wars intro to my iOS and Android mobile apps?

Brenton House — Mon, 04 May 2020 10:37:25 +0000

Dear Geek,

I really want to try to add some 3d animations to my iOS and Android mobile app built with Titanium SDK. Specifically, I am trying to recreate the Star Wars intro with the scrolling text for May the 4th. I need it to work on both iOS and Android so any guidance you can give me would be very helpful!

— TITANIUM PADAWAN

Dear Padawan,

Do or do not. There is no try! 😃🤓

Titanium Mobile SDK supports all sorts of animations and since today is May the 4th, I will do you one better and not only show you how to do the animations BUT ALSO provide you with the code you need to recreate the Star Wars intro in Titanium Mobile for BOTH iOS and Android!

TL;DR

If you are in a hurry, you can jump to the solution where I provide the source code for a working Titanium app for both iOS and Android, but I encourage you to look at some of the explanations below to help understand what the code is doing.

Check out a demo video of the completed Titanium app with the Star Wars intro!

Taking a look at the code...

Understanding Animations

There are couple things to understand about animations and the differences in the underlying platforms (iOS and Android). iOS supports 3D Matrix type animations whereas Android only supports 2D Matrix animations. That doesn't mean that we can't do what you are looking for. It just means we need to use different functions for each. Here are some of the most common classes/properties used with animating a view.

Titanium.UI.Matrix3D - Apply a 3D Matrix to a view in iOS
Titanium.UI.Matrix2D - Apply a 2D Matrix to a view in iOS and Android
Ti.UI.Animation - Apply one or more animations to any view in iOS and Android.
rotationX - Property available on every Android view that allows rotation around x-axis
rotationY - Property available on every Android view that allows rotation around y-axis

Star Wars: The Code

As you know, Titanium Mobile apps for iOS and Android are cross-platform native which means they are written in JavaScript and XML and then a native app (in Objective-C/Swift or Java) is created at compile-time. To accomplish the task of creating the Star Wars Intro, We only need one view and controller.

There are 3 basic views that we are creating:

The blue text that starts with "A long time ago in a galaxy..."
The title (May the 4th 2020 -- for this app)
The yellow text that scrolls up and back

Everything else is pretty much just the standard, default app that you get when you create a new cross-platform native mobile app using Titanium!

Star Wars: The View

The view starwars.xml will be used to define the views that we will need to create for this. Notice that some of the views are hidden (visibility = false) so that they can be shown later in the sequence.

Star Wars: The Controller

The controller starwars.js is a JavaScript file where we define and execute the animations. They are broken into 3 different functions, with each one kicking off the next after they are complete.

Solution

You can find the code for a complete working mobile application for iOS and Android that includes the Star Wars intro here! Enjoy and May the 4th be with you always!!

brentonhouse / may-the-4th

May the 4th be with you always! - Star Wars intro for iOS and Android mobile app

May the 4th be with you!

How do I add the Star Wars intro to my iOS and Android mobile apps?

Dear Geek,

I really want to try to add some 3D animations to my iOS and Android mobile app built with Titanium SDK. Specifically, I am trying to recreate the Star Wars intro with the scrolling text for May the 4th. I need it to work on both iOS and Android so any guidance you can give me would be very helpful!

— TITANIUM PADAWAN

Blog post

Read the accompanying blog post that talks about using Titanium to build a Star Wars intro in a cross-platform native mobile app for iOS and Android.

https://devblog.axway.com/mobile-apps/how-do-i-add-the-star-wars-intro-to-my-ios-and-android-mobile-apps

Demo video of mobile app with Star Wars intro

Solution

You can find the code for a complete working mobile application for iOS and Android that includes the Star Wars intro here! Enjoy and May…

View on GitHub

https://github.com/brentonhouse/may-the-4th

About Brenton House
With 25 years of experience in the development world, Brenton House leads Developer Relations for Axway's API and mobile products, He has worked closely with many clients across various industries including broadcasting, advertising, retail, financial services, transportation, publishing, supply chain, and non-profits. Brenton's passion for everything API and mobile combined with his strategy and design experience, has enabled him to help developers create captivating products that inspire and delight audiences.

About Brenton House

Ask-a-Geek questions are answered by Brenton House, an API and Mobile geek who has been doing dev work for 25+ years.

How can my Titanium iOS app detect that a screenshot has been taken?

Brenton House — Fri, 24 Apr 2020 17:15:18 +0000

Dear Geek,

Can I detect that a screenshot has been taken (like Snapchat does) on my Titanium mobile app for iOS?

— WATCHING FOR SCREENSHOTS

Dear Watching,

Good news! While there isn't a built-in way to detect that a screenshot has been taken, you can install this native module and get alerted any time a user takes a screenshot of your app.

Install @titanium/screenshot native mobile for Titanium SDK

run this in the root directory of your project

npm install @titanium/screenshot

Add code to listen for screenshot taken


// require the module
const screenshot_detective = require('@titanium/screenshot');

// add event listener
screenshot_detective.addEventListener('screenshotTaken', e => {
    console.debug('you are here → screenshot detected');
    alert('Screenshot taken!');
});

Limitations

This only works with iOS. Android is more of a pain when it comes to screenshot detection.
This will only detect screenshots taken with the physical buttons on the device (or with the simulator). It will not fire if you take a screenshot directly using the Titanium SDK.

You can find more information about detecting screenshots with Titanium Native mobile apps on the @titanium/screenshot npm page here.

About Brenton House
With 25 years of experience in the development world, Brenton House leads Developer Relations for Axway's API and mobile products, He has worked closely with many clients across various industries including broadcasting, advertising, retail, financial services, transportation, publishing, supply chain, and non-profits. Brenton's passion for everything API and mobile combined with his strategy and design experience, has enabled him to help developers create captivating products that inspire and delight audiences.

About Brenton House

Ask-a-Geek questions are answered by Brenton House, an API and Mobile geek who has been doing dev work for 25+ years.