Border AEF API Routing via Topology Hiding
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In scenarios where an API is provided by multiple exposing function network elements, the border AEF cannot determine a specific AEF to which the API invocation request should be sent, leading to failed API invocations due to the application of topology hiding policies.
Innovation Solution
A method that involves obtaining routing information and invocation parameter information to determine a target exposing function network element, allowing the border AEF to forward API invocation requests successfully to the appropriate AEF.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If topology hiding policy is applied to hide the actual AEF structure, then system security and abstraction are improved, but the ability to route API requests to the correct AEF deteriorates
Solution Approach 1:
The patent introduces a border AEF as an intermediary component that sits between the API invoker and the actual AEFs. This border AEF receives API requests and uses routing information (including AEF identifiers and serving area data) to determine the target AEF, thereby mediating the request routing process while maintaining the topology hiding policy. The intermediary enables request forwarding without exposing the internal AEF structure.
Solution Approach 2:
The patent applies preliminary action by pre-configuring routing information in the border AEF before requests arrive. The routing information includes mappings between API identifiers, AEF identifiers, and serving areas. This preliminary setup allows the border AEF to quickly determine the correct target AEF without complex real-time analysis, resolving the routing capability issue while maintaining security.
2Reliability
If multiple AEFs provide the same API to enable service redundancy, then system reliability is improved, but the complexity of determining the correct target AEF worsens
Solution Approach 1:
The patent applies local quality by associating specific attributes (serving areas) with each AEF in the routing information. Instead of treating all AEFs uniformly, the system uses location-specific quality markers to determine which AEF should handle a particular request. This allows the border AEF to make precise routing decisions based on the invoker's location and the target AEF's serving area, managing complexity through localized differentiation.
Solution Approach 2:
The patent segments the routing determination process into distinct components: routing information storage, identifier matching, and serving area verification. By dividing the complex routing task into these manageable segments, the system can handle multiple AEFs providing the same API without overwhelming complexity. Each segment performs a specific function that contributes to the overall routing decision.
Data Source
AI summary
This application provides a method and an apparatus for invoking an application programming interface (API), to determine a target exposing function network element used to invoke an API. The method includes: A first network element obtains routing information of an API, where the routing information is used to indicate a route for invoking the API, and the API is provided by a first exposing function network element and a second exposing function network element; the first network element obtains invocation parameter information of the API, where the invocation parameter information is used to handle the API; and the first network element determines a target exposing function network element in the first exposing function network element and the second exposing function network element based on the routing information and the invocation parameter information.