@@ -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:
- Java APIs: Java 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
...
...
@@ -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.
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
...
...
@@ -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.
5. Do not use or minimize the use of abbreviations. Common terms in the industry must comply with industry conventions and can be abbreviated.
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.
1. JS API module name: @ohos.\*.
2. Native API namespace: namespace OHOS.\*.
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.
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.