Review Application for the <ApiName> API in the OpenHarmony <SubsystemName> Subsystem

Background

  • API type: [Public API | System API | Test API | HDI]
  • API requirement source:
  • API usage scenario:
  • Belonging subsystem:
  • Expected API release version:
  • Contributor:
  • Number of APIs involved in this review:
Change Type Quantity Programming Language
Added
Behavior changed
Deprecated
Deleted

API Description

Necessity of the Changes

Based on the as-is and gap analysis, describe what the application scenarios and benefits of the APIs are.

Feature Overview

Describe features implemented by the APIs.

Review Conclusion

Review Conclusion from Committers

Review Conclusion from Domain SIGs

Self-Check Table

Self-Check Item Self-Check Result
Is the spelling check completed?
Are coding specifications complied with?
Are parts of speech (noun, adjective, adverb) used correctly?
Does the API name fully describe the API logic?
Is the number of API parameters appropriate? (Generally, there should be fewer than 7 parameters.)
Are abbreviations properly used? (Abbreviations used should be well known.)
Is it really that the caller of a void API does not need a return value?
Is the inheritance system appropriate? Does every method of a parent class apply to its child classes?
Are all possible error states included and defined?
Is the group of antonyms used correctly, for example:
add/remove, create/destroy, insert/delete, start/stop, begin/end,
send/receive, up/down, show/hide, open/close, source/target,
source/destination, increase/decrease, first/last, next/previous
Are the description and semantic hierarchy of new APIs consistent with those of existing APIs in the same module?
Are asynchronous counterparts needed for synchronous APIs?
Are all the public APIs truly required by developers?

API Description

Enter the code commit address.

  • Code address:

API Permission Design

Specify whether developers need to apply for certain permissions to use the APIs.

API Privacy Protection Design

If user privacy data is involved, privacy protection must be considered.

Developer Guide

Optional.

API Code Example

Select either of the following:

  • Code address:
  • Code snippet:

API Updates

Only required for existing APIs.

Behavior Change

The API behavior change indicates that the API only has its behavior changed. The new API behavior must be released in a new version. You should not change the API behavior without releasing a new version (except for defect rectification).

Reason for the Change

Deprecated APIs

Add the @deprecated annotation to the description of deprecated APIs (including JS, TS, C, and C++ APIs).

State the version from which the API is annotated by @deprecated.

Reason for Deprecation

Substitute APIs

List the APIs provided to substitute the deprecated ones. If there are no substitute APIs provided, describe the reason.

Deleted APIs

An API can be deleted only after five API versions have been released since it is marked as deprecated.

Reason for Deletion

Substitute APIs

List the APIs provided to substitute the deleted ones. If there are no substitute APIs provided, describe the reason.

DFX

Compatibility

Performance

Power Consumption

Reliability

Testability

Automatic API test cases must be delivered for all APIs.

Review Conclusion

  • Reviewed on:
  • Reviewers:
  • Review conclusion: [Pass | Fail]
  • Review meeting minutes: