Copyright©2025 Yonyou Group All rights reserved.Without the written permission of Yonyou Group, no part or whole of the content of this user manual may be copied, reproduced, translated, or reduced for any purpose. The content of this user manual may change without notice, please be aware.Please note: The content of this user manual does not represent the commitments made by Yonyou.Overall OverviewAPI management provides full life cycle management of APIs, including creation, maintenance, publishing, operation, and decommissioning. This includes product management, parameter objects, API management, plug-in management, API logs, API documentation, API access application, authorization KEY management, IP access control, rate limiting control, circuit breaker control, API registration review, and API monitoring.App ValueAPI management aims to provide a unified capability management platform for enterprise middle platform construction.Publish APIOverall OverviewProvide tenants with API publishing capabilities, allowing them to create product classifications, products, and API classifications, and then publish APIs.Overall ValueTenants can publish internal system interfaces here for API life cycle management; they can also publish interfaces for synchronization to customer development or third-party developers for use.Related ContentProduct DefinitionAPI ReleaseAPI GroupingFunction DescriptionThe first-level classification of API is Integration System. You can go to the API release menu to uniformly maintain the classification information of the API. The structure of the API is Integration System - API Classification - API.API ReleaseFunction DescriptionAPI publishing supports operations such as adding, importing, editing, deleting, publishing, unpublishing, access control, and generating documents. The organizational hierarchy for API management is Integration System - API Classification - API.API release includes Open API and Integration API:Open API: Open API refers to OpenAPI, where customers and ecosystem ISVs can securely call through API authorization.Integration API: The integration API refers to the API used in the connector for the enterprise to complete integration business.Business RuleProduct Query/View: Supports searching by API name, release status, and integrated API.API Release: Supports the addition of APIs, JSON import, JSON export, Swagger import, supports batch publishing and unpublishing of APIs, supports API documentation generation, supports API testing, and viewing API logs and monitoring.Operation InstructionsAPI Search Query:Enter the API name or path to query the APIs that meet the conditions;Support querying APIs for integrated scenarios;Support querying API by release status;Support querying API by soon-to-be-deprecated identifier;New API Classification: The first level of API classification is Integration System, and the system automatically creates the YonBIP Integration System. You can define it based on the systems used by your company. The Integration System is used for comprehensive management of integration business, such as monitoring, analysis, operation and maintenance, etc. You can choose to 【add peer classification 】 in the Integration System. If you need to perform extended development under the YonBIP system, you can skip adding a classification and directly use the YonBIP original API classification, which only supports adding new APIs and does not support modification or deletion.[Image] API Add Sibling Classification【Image】Add Subclassification to APIAfter creating the first-level classification, create the sub-classification based on the business. Click the 【Add 】 button.Publish Tenant-Level APIStep 1: Select Backend Service TypeCustom development based on YonBIP, backend service selects YouhuTong user authentication.Step 2: Basic Information[Image] Fill in Basic InformationConfiguration ItemDescriptionAPI NameThe name displayed externally for the APIAPI ClassificationSelect the terminal classification of level three or below for API classificationApplication ScenarioOpen API: i.e., OpenAPI integrated API: supports use in connectorsSecurity CertificationTo ensure call security, please select the accesstoken security certification plugin. If the notoken certification plugin is selected, no token is required to directly call the API.API CategoryEnumeration values: detail query, batch detail query, list query, single save/update, single delete, batch delete, othersEnable Simple AuthenticationDefault AppKey authentication; check "Yes" to add simple authentication if needed.IdempotencyWhether the interface supports idempotency, needs to be implemented based on the MDD frameworkUser Identity TransmissionTransmission: User bound to Appkey; no transmission: using robot account, not subject to permission controlSortingConfigure the display order of the API under the terminal classification: 1. Only positive integers can be filled in 2. If no order is filled, it will be displayed in reverse order of API creation timeAPI DescriptionDescribes the function of the interface and notes for callingAPI Classification: The API where the API is located, facilitating tenant management API. Currently, it is stipulated that an API can only be attached to one API classification. The data permission of the API is managed through the API classification, and after granting developers permission for the API classification, developers can manage the APIs under that classification.Application ScenarioOpen API: Mainly used in OpenAPI scenarios, can directly call the API through the authentication of the API Gateway.Integration API: The integration API and the open API are the same API. When it needs to be used in an integration scenario, it must be tagged, and once tagged, it can be used directly in the connector.Enable simple authentication:Simple authentication is an authentication capability provided by the API Gateway in addition to AKSK authentication. The security level of simple authentication is low and is generally used in scenarios where authentication information does not change frequently. It is not recommended for domain-released APIs. After API configuration, the API can be called using both AKSK authentication and simple authentication.In addition to marking simple authentication on the API, simple authentication needs to be enabled for the AppKey in the API call menu to obtain the AppCode for invocation.Step 3: Define API Request[Image] Define API RequestConfiguration ItemDescriptionComplete Release AddressThe address publicly available on the open platform, non-editable, format: domain + classification path + request pathClassification PathThe coding of the product line and product to which the API belongs, as part of the API release addressRequest PathThe path for the interface request, manually entered by the user. It is recommended that this address be self-explanatory, allowing the purpose of the interface to be inferred from the address. The format is: /users/{userId}/projects where the variable in {} is the request parameter, indicating a complete segment between "/", not supporting partial matches, e.g., /abc{userId}; when the request path contains request parameters, corresponding input parameter definitions must be set.Request TypeSupports GET, POST, PUT, DELETE, ANY (indicating that this API supports any request method)Match All SubpathsThe called request path will use the API request path filled in at creation as a prefix, supporting multiple different paths for interface definitions. For example: if the request path is /test/AA, using match all subpaths allows access through /test/AA/BB and /test/AA/CC, but not through /test/AACC.Input Parameter Conversion ModeInput Parameter Mapping (filter unknown parameters): indicates that parameters in Query, Header, Path, and Body Form locations need to be configured for front-end and back-end mapping. The gateway will only pass through parameters configured for the back-end, while other parameters will be filtered out. Input Parameter Mapping (pass through unknown parameters): indicates that parameters in Query, Header, Path, and Body Form locations need to be configured for front-end and back-end mapping. The gateway will not map or validate request parameters from other locations except for the configured request parameters, and user parameters will be transparently passed to the back-end. Input Parameter Pass Through: indicates that there is no need to configure Query and Body Form parameters at the input parameter definition (PATH parameters still need to be configured). All parameters sent from the client to the gateway will be passed through to the back-end by the gateway.Request ExampleThis example is required and will be displayed in the document, allowing users to refer to this example when calling the interface.Configure front-end parametersConfiguration ItemDescriptionNameThe name of the parameter. If the parameter is in the "PATH" location, the parameter name must match the name in the "request path."TypeThe type of the field, including String, int, long, boolean, object, etc. The object type can represent sub-parameters and is only displayed when the parameter location is Body.User-defined FieldIndicates whether the field is a user-defined field.Is ArrayIndicates whether the parameter is an array.DescriptionThe Chinese description of the parameter. It is recommended to clearly write the description so that the API caller can understand the meaning of the parameter in the documentation. For numeric types, it is advisable to indicate precision; for string types, it is advisable to indicate maximum length; if the value is an enumeration, it is recommended to list all enumeration values and explanations in the description.Default ValueThe default value takes effect when "Required" is "No." If this parameter is not included in the request, the API Gateway automatically adds the default value to send to the backend service.Is RequiredIndicates whether this parameter is required when requesting the API. If "Yes" is selected, the API Gateway will validate whether this parameter is included in the request; if not included, the request will be rejected.User VisibleIf set to invisible, this parameter will not be visible to users in the API documentation.ExampleAn example of how to fill in the parameter value; it is recommended to provide one.Parameter ValidationRegular expression for parameter validation. If you want to validate the format of the parameter, you can enter the corresponding regular expression here.Request ExampleThis example is required and will be displayed in the documentation, allowing users to refer to it when calling the interface.Parameter ExtensionThe parameter extension button is designed to support efficient interaction with tenant-level extension objects, and is only used in YonBIP classification scenarios. When the parameter is enabled, the API definition is directly associated with Business Object B. When the API call occurs, the backend service can receive data containing extension fields, allowing for correct data storage. The API documentation can also display extension information for the business object.Show Extension in Request ParametersIf this parameter is selected, extension fields will be added only in the request parameters.Show Extension in Return ParametersIf this parameter is selected, extension fields will be added only in the return parameters.Place Extension Parameters in customExtendIf this parameter is selected, the extension parameters will be encapsulated and transferred by customExtend. For example: customExtend{"A":"code"}.If you define the...
