@@ -20,9 +20,8 @@ OpenHarmony APIs are classified into the following types by authorized usage:
...
@@ -20,9 +20,8 @@ OpenHarmony APIs are classified into the following types by authorized usage:
OpenHarmony APIs are classified into the following types by programming language:
OpenHarmony APIs are classified into the following types by programming language:
- Java APIs: Java programming interfaces open to applications.
- JS APIs: JavaScript programming interfaces open to applications.
- JS APIs: JavaScript programming interfaces open to applications.
- Native APIs: C/C++ programming interfaces open to applications. Unless otherwise specified, the terms defined in this Charter also apply to Java APIs, JS APIs, and Native APIs.
- Native APIs: C/C++ programming interfaces open to applications. Unless otherwise specified, the terms defined in this Charter also apply to JS APIs, and Native APIs.
## API Governance
## API Governance
...
@@ -68,7 +67,7 @@ For changed APIs, except the preceding composites, the following must be include
...
@@ -68,7 +67,7 @@ For changed APIs, except the preceding composites, the following must be include
1. (Mandatory) How old APIs are handled (deprecated, hidden, or permanently deleted) and compatibility measures for developing applications using old SDKs.
1. (Mandatory) How old APIs are handled (deprecated, hidden, or permanently deleted) and compatibility measures for developing applications using old SDKs.
3. (Mandatory) Update the ChangeLog file. Update the API-diff file (Mandatory if JS/Native API changes are involved. Optional for Java API changes because this file is automatically generated using the tool and do not need to be manually submitted.)
3. (Mandatory) Update the ChangeLog file. Update the API-diff file (Mandatory if JS/Native API changes are involved.)
## API Design Requirements
## API Design Requirements
...
@@ -98,10 +97,9 @@ Design APIs from the perspective of their users rather than providers.
...
@@ -98,10 +97,9 @@ Design APIs from the perspective of their users rather than providers.
4. The larger the scope is, the more precise the naming should be.
4. The larger the scope is, the more precise the naming should be.
5. Do not use or minimize the use of abbreviations. Common terms in the industry must comply with industry conventions and can be abbreviated.
5. Do not use or minimize the use of abbreviations. Common terms in the industry must comply with industry conventions and can be abbreviated.
3. If external open-source code is referenced, retain the original package name, module name, or namespace, or replace the package name according to the preceding rules.
4. If external open-source code is referenced, retain the original package name, module name, or namespace, or replace the package name according to the preceding rules.
7. The package name, module name, and namespace must contain at least two and at most four segments. One word is recommended for each segment, and a maximum of two words are allowed.
7. The package name, module name, and namespace must contain at least two and at most four segments. One word is recommended for each segment, and a maximum of two words are allowed.
8. The class name, method name, function name, member variable, and variable name cannot exceed four words.
8. The class name, method name, function name, member variable, and variable name cannot exceed four words.