Pub/Sub APIs overview

Pub/Sub surfaces JSON/HTTP interfaces (commonly associated with RESTful systems) and gRPC interfaces.

If you don't want to use our client libraries to access the Pub/Sub API, you have the option of writing your own client libraries that use its REST or gRPC API surface. We recommend this approach only if your programming language or other needs are not met by the provided client libraries.

gRPC interface

You can generate your own gRPC client libraries in any gRPC-supported language for the Pub/Sub API from its .proto service definition using these resources:

JSON/HTTP interface

If you prefer working with the JSON/HTTP interface, you can use these resources:

About Pub/Sub endpoints

An endpoint, in the context of publish-subscribe messaging systems such as Pub/Sub, refers to a location or address where a publisher client can publish messages or where a subscriber client can receive messages.

Pub/Sub has three types of endpoints:

  • Global
  • Regional
  • Locational

Each of these endpoint types use a different value or pattern.

Global endpoint

A global endpoint in Google Cloud provides a single access point for a service.

The global endpoint for Pub/Sub is https://pubsub.googleapis.com.

Requests originating within Google Cloud

Examples of origins considered within Google Cloud include clients running on Compute Engine or App Engine. Requests to the global endpoint originating from within Google Cloud are routed to Pub/Sub in the region where they originate.

In case Pub/Sub becomes unavailable in a region, requests originating within the same Google Cloud region are not re-routed to a different region.

Requests sent over Cloud Interconnect

Requests sent to the global endpoint over Cloud Interconnect are routed just like any other request originating in the region associated with the interconnection.

Requests sent from outside of Google Cloud

Requests sent to the global endpoint from outside of Google Cloud are routed to a nearby available region. The requests may be routed to a region with insufficient project quota for the request type. The region is also not guaranteed to be the closest geographically.

Regional endpoints

Requests sent to a regional endpoint are always routed to Pub/Sub in the specified region.

Requests are never re-routed to other regions. The message storage policy must include the target region to complete the request. This helps enforce strong data residency guarantees.

For example, if you publish a Pub/Sub message to a topic through an endpoint such as pubsub.us-central1.rep.googleapis.com, the publish operation only succeeds if the following are true:

  • The topic has a message storage policy configured.
  • The message storage policy has enforce_in_transit set to true.
  • The message storage policy's allowed_persistence_regions list includes us-central1.

When to use regional endpoints

We recommend using regional endpoints as an alternative to the global one in the following cases:

  • Applications that have strict data residency constraints, requiring data to be processed in a specific region.
  • High volume applications running outside of Google Cloud that require sufficient quota in all regions where traffic might be routed.
  • Applications where the publishers or subscribers run outside of Google Cloud and are not geographically close to each other. In such cases, you can reduce Google Cloud outbound message costs by configuring the applications outside of Google Cloud to use the regional endpoint corresponding to the region used by the application inside of Google Cloud. If both publishers and subscribers are outside of Google Cloud, configure them to use the same regional endpoint.
  • When publishing with ordering.
  • When subscribing with exactly-once delivery.

Locational endpoints

Requests to a locational endpoint are almost always routed to Pub/Sub in the specified region. However, it's important to understand that locational endpoints don't provide strong data residency guarantees (like regional endpoints do).

For instance, a request to a locational endpoint might be routed to Pub/Sub in another region if you have configured a message storage policy that dictates that messages must be stored in a specific region.

When to use locational endpoints

We recommend using locational endpoints as an alternative to the global one in the following cases:

  • High volume applications running outside of Google Cloud that require sufficient quota in all regions where traffic might be routed.
  • Applications where the publishers or subscribers run outside of Google Cloud and are not geographically close to each other. In such cases, you can reduce Google Cloud outbound message costs by configuring the applications outside of Google Cloud to use the locational endpoint corresponding to the region used by the application inside of Google Cloud. If both publishers and subscribers are outside of Google Cloud, configure them to use the same locational endpoint.
  • When publishing with ordering.
  • When subscribing with exactly-once delivery.

Using endpoints

This section describes how to specify a Pub/Sub endpoint in your client.

Set a locational endpoint override

You can set a locational endpoint override for any Pub/Sub operation that calls a Pub/Sub endpoint (JSON/HTTP or gRPC).

gcloud

To set a locational endpoint override, use the CLOUDSDK_API_ENDPOINT_OVERRIDES_PUBSUB environment variable with the applicable gcloud pubsub ... command. The following example uses a locational override to publish to a topic.

CLOUDSDK_API_ENDPOINT_OVERRIDES_PUBSUB=ENDPOINT_OVERRIDE \
  gcloud pubsub topics publish TOPIC_ID \
  --message='MESSAGE_DATA'

Replace the following:

  • ENDPOINT_OVERRIDE: the locational endpoint override. Must be an absolute URI that begins with https:// and ends with a trailing /. For example, https://us-west1-pubsub.googleapis.com/.
  • TOPIC_ID: the ID of the topic.
  • MESSAGE_DATA: a string with the message data.

You can also set the a global CLOUDSDK_API_ENDPOINT_OVERRIDES_PUBSUB environment variable. If you do this, all your following Google Cloud CLI commands use the override, without requiring you to prefix the command. For example:

export CLOUDSDK_API_ENDPOINT_OVERRIDES_PUBSUB=ENDPOINT_OVERRIDE

List of locational endpoints

To send requests directly to a locational endpoint, use the following Pub/Sub endpoints:

Region Endpoint

List of regional endpoints

To send requests directly to a regional endpoint, use the following Pub/Sub endpoints:

Region Endpoint

What's next