Help Center/ Distributed Message Service for RocketMQ/ API Reference/ Before You Start
Updated on 2024-12-24 GMT+08:00
View PDF
Share

Before You Start

Welcome to Distributed Message Service for RocketMQ API Reference. Distributed Message Service (DMS) for RocketMQ is message-oriented middleware that delivers low latency, high flexibility, high throughput, dynamic expansion, easy management, and abundant messaging functions.

This document describes functions, syntax, parameters, and examples of the application programming interfaces (APIs) of DMS for RocketMQ.

DMS for RocketMQ is continuously upgraded with new functions, and the existing APIs are inevitably adjusted. For example, new response parameters may be added.

To reduce the impact of API changes, DMS for RocketMQ is backward compatible with existing APIs. When using DMS, you should accept and ignore unused parameters and parameter values in JSON responses.

DMS for RocketMQ supports Representational State Transfer (REST) APIs, allowing you to call APIs using HTTPS. For details about API calling, see Calling APIs.

Endpoints

An endpoint is the request address for calling an API. Endpoints vary depending on services and regions. For the endpoints of all services, see Regions and Endpoints.

Constraints

  • The number of instances that you can create is determined by your quota. For details, see Service Quota.
  • For more constraints, see API description.

Concepts

  • Account

    An account is created upon successful registration and has full access permissions for all of its cloud services and resources. It can be used to reset user passwords and grant user permissions. The account is a payment entity and should not be used directly to perform routine management. For security purposes, create IAM users and grant them permissions for routine management.

  • IAM user

    An Identity and Access Management (IAM) user is created using an account to use cloud services. Each IAM user has its own identity credentials (password and access keys).

    The account name, username, and password will be required for API authentication.

  • Region: A region is a geographic area in which cloud resources are deployed. Availability zones (AZs) in the same region can communicate with each other over an intranet, while AZs in different regions are isolated from each other. Deploying cloud resources in different regions can better suit certain user requirements or comply with local laws or regulations.
  • An AZ contains one or more physical data centers. Each AZ has independent cooling, fire extinguishing, moisture-proof, and electricity facilities. Within an AZ, compute, network, storage, and other resources are logically divided into multiple clusters. AZs within a region are interconnected using high-speed optical fibers to support cross-AZ high-availability systems.
  • Project

    Projects group and isolate resources (including compute, storage, and network resources) across physical regions. A default project is provided for each region, and subprojects can be created under each default project. Users can be granted permissions to access all resources in a specific project. For more refined access control, create subprojects under a project and purchase resources in the subprojects. Users can then be assigned permissions to access only specific resources in the subprojects.

    Figure 1 Project isolating model
  • Enterprise project

    Enterprise projects group and manage resources across regions. Resources in enterprise projects are logically isolated from each other. An enterprise project can contain resources of multiple regions, and resources can be added to or removed from enterprise projects.

    For details about enterprise project features and how to obtain enterprise project IDs, see the Enterprise Management User Guide.