API Design & Development
Tuesday, October 27, 2020
22,000 is the number of public APIs referenced on ProgrammableWeb. In such a competitive environment, providing good APIs is not enough.
How long does it take for your users to understand what your API does? How long to create an account? How long to make the first API call? Do you provide guides? Code samples? SDKs (generated or manually written)? Do they need to write code to test your APIs? What tooling are you offering? Are you open and transparent with your users?
In this talk, we will take a look at the things that need to come in addition to your APIs to offer the best on-boarding process and an outstanding user experience.
While APIs have clear and obvious benefits, they’re also creating a rapidly-growing attack surface that isn’t widely understood and is sometimes completely overlooked by developers and software architects. With recent reports suggesting that by 2022, API abuses will be the most responsible vector for data breaches within enterprise web applications, securing them is a top challenge and must be a bigger priority.
The first step in accomplishing this goal is generating awareness around the most critical API-related vulnerabilities and ways of protecting these programs.
This significant gap in knowledge drove me to spearhead the development of the OWASP API Security Top 10 list, which was officially published at the end of 2019, to inform organizations, developers, and security professionals about the top issues impacting API-based applications. Since deploying, it has been adopted as the de-facto standard by many organizations and security specialists.
In this talk, I'll emphasize the uniqueness of API-centric design from the security angle, highlight the risks presented by API use, and show why an increased level of awareness is required to mitigate the risks. From there, I'll dive into the top security risks presented in the OWASP API Top 10 list, and provide example attack scenarios for each. Finally, I will share what we can expect to see when it comes to API exploitation moving forward as modern software is increasingly targeted by adversaries
[TL;DR: How you can expose your existing GraphQL API as a customized REST API - without writing a single line of code]
So you’ve decided to write a public API. Great!
Should it be RESTful? Or perhaps a GraphQL API, the new cool kid on the API block? What if you already have an internal GraphQL implementation, but need to expose it publicly as REST?
In this talk, we’ll very briefly review the main differences, benefits and tradeoffs between REST and GraphQL for *public* API implementation, and go over how we at Sisense wrote a Node.js library to automatically generate a RESTful API from our existing GraphQL schema.
GraphQL2REST, which we released as an open-source npm package, allowed us to offer both API interfaces - GraphQL *and* REST - while maintaining only one code path! I'll talk about this case study and end with a live demo showing how your GraphQL API can be exposed as a customized REST API without writing a single line of code.
It might be also relevant to you, if you already have a GraphQL API, but your users want REST; or, if you want to develop a new GraphQL API and get REST on top of it, for free; or, if you wish to benefit from GraphQL internally while exposing a quite different truly RESTful API externally.
Big data and AI are present in almost every organization. The challenge is to integrate the AI needs of the enterprise with the Big data capabilities. Real time data is another dimension that adds complexity to this whole setup. There are multiple ways to tackle this issue.
In this talk, I’ll share the design principles and patterns from my experience that can help in building a Real time Big data platform for the AI needs of the enterprise. I’ll demonstrate the methods to integrate asynchronous and synchronous patterns of communication in the context of a Big Data store.
Uptime has become an extinct metric.
With the average business transaction now requiring 30 or more API connections, testing and monitoring teams are challenged to rethink which data points should be collected to improve their analytics and debugging tools. Simply relying on ping, contract, and synthetic testing has proven to be highly unreliable.
A number of API testing teams have begun their journey to go beyond uptime by building sophisticated data-driven and end-to-end functional tests that can check on entire API consumer flows. Yet most monitoring teams do not continue checking on the entire API consumer flow, despite production environments typically containing complex systems and data sets that staging does not. This raises the question: How accurate is uptime if an API is not functioning correctly?
In my demo-focused session, I will introduce attendees to the concept of "Functional Uptime," and show how API monitoring teams can easily reuse data-driven and end-to-end functional tests as monitors in production. My demo will include how to solve the problem of testing with live data in production by turning databases into APIs.
Big Takeaway: API testing and monitoring teams must break out of their siloes - a simple way is to reuse tests created by testers with high domain knowledge as monitors in production environments.