This capability integrates into mabl’s SaaS platform so that users can enhance the value of existing functional tests, move performance testing to an earlier phase of the development lifecycle, and cut down on infrastructure and operations costs.

“The primary goal is to help customers test application changes under production load before they release them so that they can detect any new bottlenecks or things that they would have experienced as the changes hit production before release,” said Dan Belcher, co-founder of mabl.

According to the company, these API load testing capabilities allow for the unification of functional and non-functional testing by utilizing functional API tests for performance and importing Postman Collections to cut down on the time it takes to create tests. 

Mabl also stated that this performance testing lowers the barrier to a sustainable and collaborative performance testing practice, even for teams that do not have dedicated performance testers or specific performance testing tools. 

“Anyone within the software team can use it, so it is not limited to just the software developers or just the performance experts,” Belcher said. “Because we’re low-code and already handling the functional testing, it makes it super easy for the teams to be able to define and execute performance tests on their own without required specialized skills.”

Furthermore, these tests can also be configured to run alongside functional tests on demand, on a schedule, or as a part of CI/CD pipelines. 

The post Mabl’s load testing offering provides increased insight into app performance appeared first on SD Times.

“APIs are the building blocks of modern software. However, those blocks have not always been accessible to everyone,” said Abhinav Asthana, co-founder and CEO of Postman. “We are on a mission to change this. With more than 25 million users across every continent, we believe Postman can accomplish this at a massive scale so that any user, anywhere, can build and participate in today’s API-first world.”

According to the company, Postman Flows is a response to the increasing demand for low-code tools that allow users to build software without a large amount of programming experience. 

With this release, users can manipulate data with API calls as well as create workflows utilizing a high volume of readily available APIs. The company stated that this makes it so that everyone can come up with solutions to common problems. 

Postman Flows was inspired by the idea of “blocks” to form and visualize an application, allowing users to drag the blogs, build the application, and deploy the workflow. Additionally, with the use of AI, users can manipulate data returned by APIs by typing out what they want to do in natural language.

“Postman Flows is the sweet spot for us, as it gives our non-technical team members a low-code tool to build, document, test, and implement an API workflow,” said Thomas Schlegel, engineer at Built Technologies. “We can accomplish tasks faster with fewer errors, and we look forward to maximizing these benefits across the organization.”

The post Postman Flows makes building software more accessible appeared first on SD Times.

For developers experimenting with AI, Google has released the PaLM API, which can be used to build on top of the company’s language models. As of today, there is an efficient model available in terms of size and capabilities, with more sizes coming soon.

The API also brings users MakerSuite, a tool that allows for prototyping ideas and will have features for prompt engineering, synthetic data generation, and custom-model-tuning, supported by safety tools.

Google is also bringing generative AI support to Google Cloud’s Vertex AI platform. This provides foundation models for generating text and images with audio and video coming in the future. With this, users can discover models, create and modify prompts, fine tune them with their own data, and deploy applications that use these new technologies.

Next, Generative AI App Builder connects conversational AI flows with search experiences and foundational models. The company stated that this tool is intended to help organizations build generative AI applications quickly.

Additionally, new features have been introduced in Google Workspace to help users utilize generative AI to create, connect, and collaborate.

A limited set of trusted testers now have access to a new set of features geared at making the process of writing easier. With this, a topic can be typed into Gmail or Google Docs and a draft will be generated.

“We’re so excited by the potential of generative AI, and the opportunities it will unlock — from helping people express themselves creatively, to helping developers build brand new types of applications, to transforming how businesses and governments engage their customers and constituents,” Thomas Kurian, CEO of Google Cloud, wrote in a blog post. 

The post Google Cloud introduces AI capabilities to simplify building with Google’s AI models appeared first on SD Times.

AWS Application Composer allows for building prototypes of serverless applications and collaboratively reviewing them, generating diagrams for documentation or Wikis, and onboarding new team members to a project, according to Amazon. 

“Developers that never used serverless before, how do they know where to start? Which services do they need? How do they work together? We really wanted to make this easier. AWS Application Composer simplifies and accelerates the architecting, configuring, and building of serverless applications,” Dr. Werner Vogels, CTO of Amazon.com said at the re:Invent 2022 keynote, where the application was first previewed. 

Since the initial announcements, AWS Application Composer has received many improvements. 

One such improvement is a new feature that improves how to work with Amazon Simple Queue Service (SQS) queues. By removing the need to route requests through an AWS Lambda function and decreasing the lines of code, Amazon API Gateway resources can now be directly connected to Amazon SQS, which increases reliability.

Also, a new Change Inspector provides a visual breakdown of template changes between two resources when they are connected on the canvas. 

There have been some notable improvements to the UI since the preview. The size of resource cards has been reduced and users can zoom in and out and zoom to fit buttons to show the entire screen or the desired zoom level. 

The post AWS’ low code serverless app builder enables prototyping appeared first on SD Times.

The platform provides an advanced technology stack, which allows multiple users to edit together in real-time or with the ‘Operational Transformation’ algorithm.

It also includes a user-friendly database spreadsheet interface and database-native architecture through Changeset / Operation / Action / Snapshot.

The database spreadsheet UI enables users to use separated workspaces in place of App/Base-based structure and make unlimited tables link together. It includes dark mode and theme customization in addition to seven view types and a one-click API panel. 

Users can also activate row permissions with a single click through the Mirror functionality.

APITable is easily extensible and allows users to customize graph and chart dashboards, data column types, automation robot actions and more. 

It comes equipped with enterprise features such as SAML, single sign-on, database auto backup, a data exporter, the ability to auditor and watermark.

Additional details on APITable are available here. 

The post SD Times Open-Source Project of the Week: APITable appeared first on SD Times.

With 70% of respondents to a report expecting to use more APIs in 2023 than last year, this presents a heightened challenge for API security, which only comprises about 4% of the testing efforts at organizations today. 

The 4th annual State of the APIs Report collected insights from more than 850 global developers, engineers, and leaders from across the technology community spanning over 100 countries including the US, the UK, Germany, and India.

The increased API usage is especially prominent in telecommunications, which is projected to rise to 72%, up from 59% last year. This is followed by smaller, yet still considerable, increases in the fields of technology and professional services. 

Mark O’Neill, VP analyst, and chief of research for software engineering at Gartner, correctly predicted in 2021 that by this year, API breaches would be the number one threat vector for web applications. 

“Part of the reason for that is because with mobile and web apps, along with any other type of modern application that you’re using, it all involves the use of APIs,” O’Neill said. 

Gartner research has estimated that by 2025, fewer than half of enterprise APIs will be managed, as explosive growth in APIs surpasses the capabilities of API management tools and “security controls try to apply old paradigms to new problems.”

This vast number of APIs floating around the organization is further complicated by multiple teams building and managing APIs all while using different cloud platforms and frameworks, according to O’Neill. 

“When you have different platforms where your teams are building and deploying APIs, there’s no one place to put the gateway, which is a problem for traditional API management solutions,” O’Neill said. 

To secure this wide API landscape, many companies have put up multiple gateways, which means that now there are more gateways in front of APIs, but it created a new problem of learning how to manage all of these gateways together. 

“Many clients have asked us for a federated solution that would work across different API gateways and allow teams to have a single picture of their API traffic and to have a single control plane for management and security, but at the moment, that is a gap in the market,” O’Neill said. 

A single federated solution would allow users to set up authentication and authorization schemes across different APIs, ensuring that only the right users have access to the right resources. It also enables administrators to set up rate limiting and other security measures, such as IP white/blacklisting, to protect against malicious attacks. 

With such a solution, teams would also gain visibility into API performance and usage, allowing teams to identify and address potential security issues quickly.

A hodgepodge of APIs in use

The other problem APIs present for API management solutions is that there are many different types of APIs in use.

The API jumble often consists of REST, Webhooks, Websockets, SOAP, GraphQL, Kafka, AsyncAPIs, gRPCs, if not more. 

“If you look at a typical organization that has deployed API management, they may believe that all of their APIs are being managed on one platform,” O’Neill said. “But typically, there are a lot of other APIs that they have that are part of web applications, part of mobile apps, and they’re not managed, they’re effectively under the radar for that organization. And these are the ones that get breached.”

The APIs to watch out for in particular are GraphQLs, according to O’Neill. Users can do very wide and deep queries on data, which can also be their downside because it’s difficult to set up proper access control rules. The complexity of the query can make it hard to predict what data will be accessible. 

Additionally, the use of variables in queries can make it difficult to prevent malicious users from exploiting the API. GraphQL APIs are often stateless, which means that security teams need to ensure that all requests are properly authenticated and authorized. These types of APIs are also new so many organizations are just building up their security teams’ skills around GraphQL and graph APIs in general. 

Another challenge is to consider where all of your APIs are coming from. 

While internal APIs were still the most common API type developers reported working on for their organization, more developers in 2022 reported working on partner-facing or third-party APIs than the year prior. In addition, the SaaS applications that developers utilize also often use their own set of APIs. 

The percentage of developers who reported working on partner-facing and third-party APIs grew by almost 5% in 2022 compared to 2021, according to the 2022 State of the API report. This change was even more dramatic with partner-facing APIs in industries like technology, which grew by nearly 10%.

One hotspot of security issues tends to be around the APIs that require access to data: customer data, preferences, and all sorts of account information. Issues also surround APIs that run a function to do something because often that requires a transaction, so payment information might be at risk, O’Neill said. 

“One is the whole area of loyalty cards where you get points for making purchases, traveling, and so on. Those involve many APIs. So you have an API to look up how many points a certain person has or you have an API to spend the points. We’ve seen security breaches where attackers have been able to find people who have accrued many points and then spend those,” O’Neill said. “Often the person is not aware, because they simply were not aware that they were running up all these points in the first place, and then they’re not aware when they get spent.”

Best practices for API security

The first step for ensuring API security is to catalog all of the APIs in the organization and to have an inventory. Often, companies only look at their existing API gateway to see what APIs are registered there, but even multiple gateways don’t paint the complete picture, O’Neill explained. 

“The way that we advise people to do this is to see what APIs your business depends on,” O’Neill said. “So those of course can be your own APIs, but they can also be important to APIs that you’re consuming from third parties as well. It’s going to be a problem if those APIs suffer a security breach, if they are unavailable, or if they are just simply changing and creating breaking changes. So API discovery is a hard problem because you have to look in multiple places for the APIs.” 

One approach is to simply ask the internal product managers who are then speaking to engineering leaders about what APIs the teams are building. 

There are also some solutions on the market that enable users to tap into application firewalls in the infrastructure at the CDN level to look at the traffic and see what API calls are happening. 

“That approach can in many ways be too late because those APIs that you’re discovering are already in production. But still, it’s better than not discovering them at all,” O’Neill said. 

Using APIs to increase security

By collaborating with APIs, organizations can become more secure as a whole. One such example occurred in the Open Banking Initiative that started in Europe but has since spread in popularity to North America.

The Open Banking Initiative began in January 2016, when the Competition and Markets Authority (CMA) in the UK issued a directive ordering the country’s nine largest banks to open up their customer data to third-party providers.

Since then, it has become valuable because it has allowed financial institutions to create Open APIs that outside organizations and their third-party developers can leverage, according to MuleSoft in a blog post. 

Rather than opening up the APIs to attack, the initiative enabled a secure form of data exchange that accelerates collaboration with outside organizations and has decreased the risks associated with screen scraping, a technique used by programs to extract data from the human-readable output of a computer application. 

Screen scraping is insecure because it requires customers to provide third-party aggregators with login credentials and it also pushes significant traffic to servers with every “scrape.”

Open Banking initiatives offer financial institutions the opportunity to safely collaborate with third-party developers through APIs. Unlike screen scraping, this secure data exchange is API-enabled and does not strain or overload servers. 

Market forecast for 2023

Cyberattacks and data breaches don’t pause with an economic slowdown. When prioritizing security investments, security leaders should continue to invest in security controls and solutions that protect the organization’s customer-facing and revenue-generating workloads, as well as any infrastructure critical to health and safety for those organizations in industries such as utilities, energy, and transportation, according to Forrester in its Planning Guide 2023: Security & Risk.

“API-first is the de facto modern development approach, and APIs help organizations create new business models and methods of engagement with customers and partners. However, security breaches due to unprotected APIs and API endpoints are common and no single type of tool fully addresses API security,” the guide states. 

API management tools address authentication and authorization issues, while API-specific security tools are used for scanning and discovery. Additionally, some security tools extend further to provide runtime protections and microgateways to protect against API attacks. Traditional security tools such as WAFs and bot management solutions are also expanding to cover these attacks, the report added. 

Gartner’s O’Neill said that he is seeing large vendors take steps forward in providing strong API protection and are acquiring some of the smaller specialist vendors that have come along for API protection as well. 

According to the 2022 State of APIs report, 69% of developers said that they expect to use APIs more in 2023 while 25% said that they expect about the same. Only about 6% stated that they expect less or they didn’t know. 

The post Time to hide your API appeared first on SD Times.

The new version includes custom attributes for ‘[ObservableProperty].’ With no constraints on the types of attributes that this feature supports, this allows complete flexibility in annotations for generated properties, all while using built-in C# syntax.

The release is also the first one to introduce dedicated analyzers so that the MVVM Toolkit will no longer just emit diagnostics for features used incorrectly, but will also show recommendations to improve the code and avoid common errors.

The first analyzer will alert users when they assign values to fields that support an observable property, prompting them to use the generated property instead. The second analyzer can shrink the size of binaries in applications that utilize the MVVM Toolkit.

The new version has also added multi-targeting for Roslyn 4.3 so that the MVVM Toolkit source generators will now use the Roslyn 4.3 target if supported.

Thanks to the new IObservable<T> extensions for the IMessenger interface, developers who heavily utilize Reactive-style APIs in their applications can now bridge the functionality exposed by the messenger APIs in the MVVM Toolkit, a feature they had heavily requested.

The new release of the Toolkit adds .NET 7TFM to the HighPerformance package and it includes several changes to benefit from the new C# 11 language features.

The post .NET Toolkit 8.1 released appeared first on SD Times.

This release introduces support for simulating errors on Microsoft Graph and other APIs as well as contextual guidance to help improve app performance.

According to the company, Microsoft Graph and SharePoint APIs are included in the new release by default. Users can then extend it in order to include other APIs by adding the URLs that the Proxy should intercept.

Users can also extend requests to Microsoft Graph by using the $select query parameter. This works to limit the data Microsoft Graph returns to only what is needed by a specific application. 

Additionally, users will also be made aware of any requests made to Microsoft Graph API that do not use the $select parameter as well as provide a link to offer more information about using the parameter.

With this new release, the team at Microsoft also announced that they are also working on improving the readability of the Proxy’s output in order to make it easier for users to follow different messages as more features are added to the Graph Developer Proxy.

The company also stated that it is looking into ways to help users better understand which beta endpoints are being used in applications so that they can update them to use v1.0 endpoints that are supported in production. 

Lastly, the Microsoft team is working on refactoring the Microsoft Graph Proxy in order to make it more modular. This will simplify the process of maintaining different features in the future as well as offer users the opportunity to construct plugins to support specific scenarios. 

For more information, read the blog post. To download Microsoft Graph Developer Proxy v0.3, click here. 

The post Microsoft releases Graph Developer Proxy preview v0.3 appeared first on SD Times.

What is API Developer Experience (DX)?

Simply said, DX refers to the question of how well an API works as a product that a developer is using to build an application. This means that very specifically, DX is not about the functionality of the API (i.e., about the service that is delivered through the API), but about the usability of the API itself. DX is just about the interface.

Practically speaking, DX is measuring how easy an API can be used by the developer for building an application. Specifically, this does not include the question of how useful that application will then be for users.

This means that the perspective of DX is relatively narrow. It just involves the API and the ease of building an application with it. This brings us to questions that take a slightly wider perspective and go beyond just looking at an API and the application that’s built with it.

What else matters for API success?

While it’s certainly useful for a developer to be able to easily build an application, there is also the question of who that application is for. This brings the end user into perspective, i.e. the user of an application that leverages the service the API delivers.

A second step back looks at the even bigger question of why that service is provided in the first place. Certainly, there are many services that users would enjoy, but there must also be an underlying value model that makes it reasonable for a service provider to provide such an API.

Let’s look at these two issues in a bit more detail.

User Experience (UX)

By their very definition, APIs are used by applications. These applications then are, directly or indirectly, consumed by users who are exposed to a User Experience (UX). These users should find the application useful, and the API then helped to create that useful application. 

That’s rather different from DX, which only looks at how usable the API is, but doesn’t include a perspective that involves the end user.

What this means is that UX is at least as important as DX. There could be a perfectly usable API that would make it fantastically easy for developers to build applications with it, but if it doesn’t contribute to the usefulness of the applications built with it, it would never be widely used (other than maybe as an educational API for great DX).

Value Exchange (VX)

But the perspective must be even broader than that. Because even if you can think of a perfectly usable API that’s providing an extremely useful service, there must be somebody bearing the cost of designing, implementing, and operating it. There must be a Value Exchange (VX) happening that means that the provider is willing to provide the service through the API.

In most cases, this VX may be based on economics, but even for economics, that’s a very wide range of possible motivations. For example, if a government improves the life of citizens by providing a service through an API, then this improvement of the quality of life may be sufficient for the value models that are often used in public sector economics.

As we can see, VX is an even bigger factor than UX or DX. If there is no value exchange that justifies the existence of a service, then there is no sustainable foundation to provide it.

What does all of this mean for my API program?

As mentioned in the introduction, the idea here is not to belittle DX. We all want our APIs to be usable and used, and it’s important to invest in DX so that APIs see as much adoption as possible. It would be a shame to cripple a useful service by delivering it through a badly usable API.

But just focusing on DX sets a rather narrow focus. We must also always think about the usefulness (UX) of an API, and we also need to think about its viability (VX). Without taking those aspects into consideration, we may overinvest in DX and forget to take the bigger picture into account.

One last word about DX: Many examples and motivations discussing DX explicitly or implicitly assume that there’s competition. Sometimes that’s the case, but looking at all of an organization’s APIs, there often are very few if any APIs that have competition. 

Of course, if you’re providing an “Product-as-an-API” and there are competing providers, then DX can become an extremely important differentiating factor. Some of you may remember Twilio’s “Ask Your Developer” campaign that explicitly targeted this differentiation. But it’s important to keep in mind that APIs such as this are a small fraction of API landscapes in today’s organizations, and it’s wise to invest accordingly.

The post Is API developer experience overrated? appeared first on SD Times.

The release adds support for Tuner Hal 2.0, an interface between the framework and vendors,  with performance optimizations, twin tuner and ISDB-T Multi-Layer support

An improvement to the AudioManager API enables audio attribute support for the active audio device and the ability to select an optimal format without starting playback. Users can also change the default resolution and refresh rate on supported HDMI source devices and HDMI state changes are now surfaced to the MediaSession lifecycle.

The InputDevice API, which allows developers to access information about connected input devices, including keyboards, game controllers, and other input devices, now supports different layouts of physical keyboards.

Also, an audio descriptions API in AccessibilityManager allows apps to query system-wide audio description preference settings.

If developers have the ADT-3 Developer Kit, they can install a system image or use Android Emulator for TV, which allows them to try out new user interface capabilities like audio routing, keyboard layouts and HDMI state changes.

The post Android 13 for TV now available with improvements to accessibility appeared first on SD Times.