Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Method and Apparatus for Matching Application Programming Interface (API) Paths with Templates

IP.com Disclosure Number: IPCOM000248603D
Publication Date: 2016-Dec-21
Document File: 4 page(s) / 48K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is an algorithm that provides a runtime-optimized mechanism that a gateway can use to match an incoming request to an operation and predefined behaviors using a number of criteria.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 37% of the total text.

1

Method and Apparatus for Matching Application Programming Interface (API) Paths with Templates

According to the Open Application Programming Interface (OpenAPI) specification, API operations may be specified in a way that allows portions of the associated Uniform Resource Locator (URL) path to be expressed as a template. This variability poses challenges for a gateway that enforces non-functional requirements of a service because of the ambiguity involved in trying to determine whether an incoming request matches an operation defined in the API. (Figure 1)

Figure 1: Consider this simple pet API example

Ambiguity would be encountered by a request, "GET: /pet/findByStatus", which matches the operations "GET: /pet/findByStatus" and "GET: /pet/{petId}" above because either operation could be considered a valid match. In this example, it is simple to determine that the exact match should take precedence over the inexact match, but the task is not so simple when no exact matches exist or when paths contain one or more templates that vary by one or more positions.

This is complicated even further when the notion of a subscription is introduced. A client might subscribe to a plan, which may be a subset of operations of an API and may specify non-functional requirements (e.g., rate limit for the plan or operations), allowing different levels of service for subscribers of an API. For example, a high-level plan subscriber may be entitled to use all operations in the pet API, but a lower-level subscriber may not be entitled to call the "GET: /pet/findByStatus" operation. The gateway should reject a request for "GET: /pet/findByStatus" instead of allowing it to pass because it matches "GET: /pet/{petId}".

The novel contribution is an algorithm that fulfills the aforementioned requirements in a deterministic way that optimizes the performance of runtime enforcement. This solution provides a runtime-optimized mechanism that a gateway can use to match an incoming request to an operation and predefined behaviors using the following criteria:

 Path length (if applicable)  Hypertext Transfer Protocol (HTTP) method (if applicable)  Match expressions  Match score (aka match expression score)

2

 Security criteria  Subscription/entitlement criteria (allow/deny based on API subscription)

This solution comprises a deploy-time context and a run-time context.

In the deploy-time context, the method is to iterate all subscriptions and create a flat list of all possible operations that will run through the gateway. The list contains an entry for every operation defined in every API for every subscription. Furthermore, the process generates the match expression from the path template provided in the API, calculates a score for this match expression, and stores it in the optimized model (the approach results in a Central Processing Unit (CPU) vs. memory trade-off).

The core novelty is the match score calculation, which is as follows: Given a set of match expressions...