| <html><body> |
| <style> |
| |
| body, h1, h2, h3, div, span, p, pre, a { |
| margin: 0; |
| padding: 0; |
| border: 0; |
| font-weight: inherit; |
| font-style: inherit; |
| font-size: 100%; |
| font-family: inherit; |
| vertical-align: baseline; |
| } |
| |
| body { |
| font-size: 13px; |
| padding: 1em; |
| } |
| |
| h1 { |
| font-size: 26px; |
| margin-bottom: 1em; |
| } |
| |
| h2 { |
| font-size: 24px; |
| margin-bottom: 1em; |
| } |
| |
| h3 { |
| font-size: 20px; |
| margin-bottom: 1em; |
| margin-top: 1em; |
| } |
| |
| pre, code { |
| line-height: 1.5; |
| font-family: Monaco, 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', 'Lucida Console', monospace; |
| } |
| |
| pre { |
| margin-top: 0.5em; |
| } |
| |
| h1, h2, h3, p { |
| font-family: Arial, sans serif; |
| } |
| |
| h1, h2, h3 { |
| border-bottom: solid #CCC 1px; |
| } |
| |
| .toc_element { |
| margin-top: 0.5em; |
| } |
| |
| .firstline { |
| margin-left: 2 em; |
| } |
| |
| .method { |
| margin-top: 1em; |
| border: solid 1px #CCC; |
| padding: 1em; |
| background: #EEE; |
| } |
| |
| .details { |
| font-weight: bold; |
| font-size: 14px; |
| } |
| |
| </style> |
| |
| <h1><a href="firebaserules_v1.html">Firebase Rules API</a> . <a href="firebaserules_v1.projects.html">projects</a> . <a href="firebaserules_v1.projects.releases.html">releases</a></h1> |
| <h2>Instance Methods</h2> |
| <p class="toc_element"> |
| <code><a href="#create">create(name=None, body, x__xgafv=None)</a></code></p> |
| <p class="firstline">Create a `Release`.</p> |
| <p class="toc_element"> |
| <code><a href="#delete">delete(name=None, x__xgafv=None)</a></code></p> |
| <p class="firstline">Delete a `Release` by resource name.</p> |
| <p class="toc_element"> |
| <code><a href="#get">get(name=None, x__xgafv=None)</a></code></p> |
| <p class="firstline">Get a `Release` by name.</p> |
| <p class="toc_element"> |
| <code><a href="#list">list(name=None, pageSize=None, filter=None, pageToken=None, x__xgafv=None)</a></code></p> |
| <p class="firstline">List the `Release` values for a project. This list may optionally be</p> |
| <p class="toc_element"> |
| <code><a href="#list_next">list_next(previous_request, previous_response)</a></code></p> |
| <p class="firstline">Retrieves the next page of results.</p> |
| <p class="toc_element"> |
| <code><a href="#update">update(name=None, body, x__xgafv=None)</a></code></p> |
| <p class="firstline">Update a `Release`.</p> |
| <h3>Method Details</h3> |
| <div class="method"> |
| <code class="details" id="create">create(name=None, body, x__xgafv=None)</code> |
| <pre>Create a `Release`. |
| |
| Release names should reflect the developer's deployment practices. For |
| example, the release name may include the environment name, application |
| name, application version, or any other name meaningful to the developer. |
| Once a `Release` refers to a `Ruleset`, the rules can be enforced by |
| Firebase Rules-enabled services. |
| |
| More than one `Release` may be 'live' concurrently. Consider the following |
| three `Release` names for `projects/foo` and the `Ruleset` to which they |
| refer. |
| |
| Release Name | Ruleset Name |
| --------------------------------|------------- |
| projects/foo/releases/prod | projects/foo/rulesets/uuid123 |
| projects/foo/releases/prod/beta | projects/foo/rulesets/uuid123 |
| projects/foo/releases/prod/v23 | projects/foo/rulesets/uuid456 |
| |
| The table reflects the `Ruleset` rollout in progress. The `prod` and |
| `prod/beta` releases refer to the same `Ruleset`. However, `prod/v23` |
| refers to a new `Ruleset`. The `Ruleset` reference for a `Release` may be |
| updated using the UpdateRelease method, and the custom `Release` name |
| may be referenced by specifying the `X-Firebase-Rules-Release-Name` header. |
| |
| Args: |
| name: string, Resource name for the project which owns this `Release`. |
| |
| Format: `projects/{project_id}` (required) |
| body: object, The request body. (required) |
| The object takes the form of: |
| |
| { # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a |
| # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`. |
| "updateTime": "A String", # Time the release was updated. |
| # @OutputOnly |
| "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must |
| # exist the `Release` to be created. |
| "createTime": "A String", # Time the release was created. |
| # @OutputOnly |
| "name": "A String", # Resource name for the `Release`. |
| # |
| # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2` |
| # which affords developers a great deal of flexibility in mapping the name |
| # to the style that best fits their existing development practices. For |
| # example, a name could refer to an environment, an app, a version, or some |
| # combination of three. |
| # |
| # In the table below, for the project name `projects/foo`, the following |
| # relative release paths show how flat and structured names might be chosen |
| # to match a desired development / deployment strategy. |
| # |
| # Use Case | Flat Name | Structured Name |
| # -------------|---------------------|---------------- |
| # Environments | releases/qa | releases/qa |
| # Apps | releases/app1_qa | releases/app1/qa |
| # Versions | releases/app1_v2_qa | releases/app1/v2/qa |
| # |
| # The delimiter between the release name path elements can be almost anything |
| # and it should work equally well with the release name list filter, but in |
| # many ways the structured paths provide a clearer picture of the |
| # relationship between `Release` instances. |
| # |
| # Format: `projects/{project_id}/releases/{release_id}` |
| } |
| |
| x__xgafv: string, V1 error format. |
| Allowed values |
| 1 - v1 error format |
| 2 - v2 error format |
| |
| Returns: |
| An object of the form: |
| |
| { # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a |
| # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`. |
| "updateTime": "A String", # Time the release was updated. |
| # @OutputOnly |
| "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must |
| # exist the `Release` to be created. |
| "createTime": "A String", # Time the release was created. |
| # @OutputOnly |
| "name": "A String", # Resource name for the `Release`. |
| # |
| # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2` |
| # which affords developers a great deal of flexibility in mapping the name |
| # to the style that best fits their existing development practices. For |
| # example, a name could refer to an environment, an app, a version, or some |
| # combination of three. |
| # |
| # In the table below, for the project name `projects/foo`, the following |
| # relative release paths show how flat and structured names might be chosen |
| # to match a desired development / deployment strategy. |
| # |
| # Use Case | Flat Name | Structured Name |
| # -------------|---------------------|---------------- |
| # Environments | releases/qa | releases/qa |
| # Apps | releases/app1_qa | releases/app1/qa |
| # Versions | releases/app1_v2_qa | releases/app1/v2/qa |
| # |
| # The delimiter between the release name path elements can be almost anything |
| # and it should work equally well with the release name list filter, but in |
| # many ways the structured paths provide a clearer picture of the |
| # relationship between `Release` instances. |
| # |
| # Format: `projects/{project_id}/releases/{release_id}` |
| }</pre> |
| </div> |
| |
| <div class="method"> |
| <code class="details" id="delete">delete(name=None, x__xgafv=None)</code> |
| <pre>Delete a `Release` by resource name. |
| |
| Args: |
| name: string, Resource name for the `Release` to delete. |
| |
| Format: `projects/{project_id}/releases/{release_id}` (required) |
| x__xgafv: string, V1 error format. |
| Allowed values |
| 1 - v1 error format |
| 2 - v2 error format |
| |
| Returns: |
| An object of the form: |
| |
| { # A generic empty message that you can re-use to avoid defining duplicated |
| # empty messages in your APIs. A typical example is to use it as the request |
| # or the response type of an API method. For instance: |
| # |
| # service Foo { |
| # rpc Bar(google.protobuf.Empty) returns (google.protobuf.Empty); |
| # } |
| # |
| # The JSON representation for `Empty` is empty JSON object `{}`. |
| }</pre> |
| </div> |
| |
| <div class="method"> |
| <code class="details" id="get">get(name=None, x__xgafv=None)</code> |
| <pre>Get a `Release` by name. |
| |
| |
| Args: |
| name: string, Resource name of the `Release`. |
| |
| |
| Format: `projects/{project_id}/releases/{release_id}` (required) |
| x__xgafv: string, V1 error format. |
| Allowed values |
| 1 - v1 error format |
| 2 - v2 error format |
| |
| Returns: |
| An object of the form: |
| |
| { # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a |
| # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`. |
| "updateTime": "A String", # Time the release was updated. |
| # @OutputOnly |
| "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must |
| # exist the `Release` to be created. |
| "createTime": "A String", # Time the release was created. |
| # @OutputOnly |
| "name": "A String", # Resource name for the `Release`. |
| # |
| # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2` |
| # which affords developers a great deal of flexibility in mapping the name |
| # to the style that best fits their existing development practices. For |
| # example, a name could refer to an environment, an app, a version, or some |
| # combination of three. |
| # |
| # In the table below, for the project name `projects/foo`, the following |
| # relative release paths show how flat and structured names might be chosen |
| # to match a desired development / deployment strategy. |
| # |
| # Use Case | Flat Name | Structured Name |
| # -------------|---------------------|---------------- |
| # Environments | releases/qa | releases/qa |
| # Apps | releases/app1_qa | releases/app1/qa |
| # Versions | releases/app1_v2_qa | releases/app1/v2/qa |
| # |
| # The delimiter between the release name path elements can be almost anything |
| # and it should work equally well with the release name list filter, but in |
| # many ways the structured paths provide a clearer picture of the |
| # relationship between `Release` instances. |
| # |
| # Format: `projects/{project_id}/releases/{release_id}` |
| }</pre> |
| </div> |
| |
| <div class="method"> |
| <code class="details" id="list">list(name=None, pageSize=None, filter=None, pageToken=None, x__xgafv=None)</code> |
| <pre>List the `Release` values for a project. This list may optionally be |
| filtered by `Release` name or `Ruleset` id or both. |
| |
| Args: |
| name: string, Resource name for the project. |
| |
| Format: `projects/{project_id}` (required) |
| pageSize: integer, Page size to load. Maximum of 100. Defaults to 10. |
| Note: `page_size` is just a hint and the service may choose to load less |
| than `page_size` due to the size of the output. To traverse all of the |
| releases, caller should iterate until the `page_token` is empty. |
| filter: string, `Release` filter. The list method supports filters with restrictions on the |
| `Release` `name` and also on the `Ruleset` `ruleset_name`. |
| |
| Example 1) A filter of 'name=prod*' might return `Release`s with names |
| within 'projects/foo' prefixed with 'prod': |
| |
| Name | Ruleset Name |
| ------------------------------|------------- |
| projects/foo/releases/prod | projects/foo/rulesets/uuid1234 |
| projects/foo/releases/prod/v1 | projects/foo/rulesets/uuid1234 |
| projects/foo/releases/prod/v2 | projects/foo/rulesets/uuid8888 |
| |
| Example 2) A filter of `name=prod* ruleset_name=uuid1234` would return only |
| `Release` instances for 'projects/foo' with names prefixed with 'prod' |
| referring to the same `Ruleset` name of 'uuid1234': |
| |
| Name | Ruleset Name |
| ------------------------------|------------- |
| projects/foo/releases/prod | projects/foo/rulesets/1234 |
| projects/foo/releases/prod/v1 | projects/foo/rulesets/1234 |
| |
| In the examples, the filter parameters refer to the search filters for |
| release and ruleset names are relative to the project releases and rulesets |
| collections. Fully qualified prefixed may also be used. e.g. |
| `name=projects/foo/releases/prod* ruleset_name=projects/foo/rulesets/uuid1` |
| pageToken: string, Next page token for the next batch of `Release` instances. |
| x__xgafv: string, V1 error format. |
| Allowed values |
| 1 - v1 error format |
| 2 - v2 error format |
| |
| Returns: |
| An object of the form: |
| |
| { # The response for FirebaseRulesService.ListReleases. |
| "nextPageToken": "A String", # The pagination token to retrieve the next page of results. If the value is |
| # empty, no further results remain. |
| "releases": [ # List of `Release` instances. |
| { # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a |
| # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`. |
| "updateTime": "A String", # Time the release was updated. |
| # @OutputOnly |
| "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must |
| # exist the `Release` to be created. |
| "createTime": "A String", # Time the release was created. |
| # @OutputOnly |
| "name": "A String", # Resource name for the `Release`. |
| # |
| # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2` |
| # which affords developers a great deal of flexibility in mapping the name |
| # to the style that best fits their existing development practices. For |
| # example, a name could refer to an environment, an app, a version, or some |
| # combination of three. |
| # |
| # In the table below, for the project name `projects/foo`, the following |
| # relative release paths show how flat and structured names might be chosen |
| # to match a desired development / deployment strategy. |
| # |
| # Use Case | Flat Name | Structured Name |
| # -------------|---------------------|---------------- |
| # Environments | releases/qa | releases/qa |
| # Apps | releases/app1_qa | releases/app1/qa |
| # Versions | releases/app1_v2_qa | releases/app1/v2/qa |
| # |
| # The delimiter between the release name path elements can be almost anything |
| # and it should work equally well with the release name list filter, but in |
| # many ways the structured paths provide a clearer picture of the |
| # relationship between `Release` instances. |
| # |
| # Format: `projects/{project_id}/releases/{release_id}` |
| }, |
| ], |
| }</pre> |
| </div> |
| |
| <div class="method"> |
| <code class="details" id="list_next">list_next(previous_request, previous_response)</code> |
| <pre>Retrieves the next page of results. |
| |
| Args: |
| previous_request: The request for the previous page. (required) |
| previous_response: The response from the request for the previous page. (required) |
| |
| Returns: |
| A request object that you can call 'execute()' on to request the next |
| page. Returns None if there are no more items in the collection. |
| </pre> |
| </div> |
| |
| <div class="method"> |
| <code class="details" id="update">update(name=None, body, x__xgafv=None)</code> |
| <pre>Update a `Release`. |
| |
| Only updates to the `ruleset_name` field will be honored. `Release` rename |
| is not supported. To create a `Release` use the CreateRelease method |
| instead. |
| |
| Args: |
| name: string, Resource name for the `Release`. |
| |
| `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2` |
| which affords developers a great deal of flexibility in mapping the name |
| to the style that best fits their existing development practices. For |
| example, a name could refer to an environment, an app, a version, or some |
| combination of three. |
| |
| In the table below, for the project name `projects/foo`, the following |
| relative release paths show how flat and structured names might be chosen |
| to match a desired development / deployment strategy. |
| |
| Use Case | Flat Name | Structured Name |
| -------------|---------------------|---------------- |
| Environments | releases/qa | releases/qa |
| Apps | releases/app1_qa | releases/app1/qa |
| Versions | releases/app1_v2_qa | releases/app1/v2/qa |
| |
| The delimiter between the release name path elements can be almost anything |
| and it should work equally well with the release name list filter, but in |
| many ways the structured paths provide a clearer picture of the |
| relationship between `Release` instances. |
| |
| Format: `projects/{project_id}/releases/{release_id}` |
| (required) |
| body: object, The request body. (required) |
| The object takes the form of: |
| |
| { # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a |
| # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`. |
| "updateTime": "A String", # Time the release was updated. |
| # @OutputOnly |
| "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must |
| # exist the `Release` to be created. |
| "createTime": "A String", # Time the release was created. |
| # @OutputOnly |
| "name": "A String", # Resource name for the `Release`. |
| # |
| # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2` |
| # which affords developers a great deal of flexibility in mapping the name |
| # to the style that best fits their existing development practices. For |
| # example, a name could refer to an environment, an app, a version, or some |
| # combination of three. |
| # |
| # In the table below, for the project name `projects/foo`, the following |
| # relative release paths show how flat and structured names might be chosen |
| # to match a desired development / deployment strategy. |
| # |
| # Use Case | Flat Name | Structured Name |
| # -------------|---------------------|---------------- |
| # Environments | releases/qa | releases/qa |
| # Apps | releases/app1_qa | releases/app1/qa |
| # Versions | releases/app1_v2_qa | releases/app1/v2/qa |
| # |
| # The delimiter between the release name path elements can be almost anything |
| # and it should work equally well with the release name list filter, but in |
| # many ways the structured paths provide a clearer picture of the |
| # relationship between `Release` instances. |
| # |
| # Format: `projects/{project_id}/releases/{release_id}` |
| } |
| |
| x__xgafv: string, V1 error format. |
| Allowed values |
| 1 - v1 error format |
| 2 - v2 error format |
| |
| Returns: |
| An object of the form: |
| |
| { # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a |
| # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`. |
| "updateTime": "A String", # Time the release was updated. |
| # @OutputOnly |
| "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must |
| # exist the `Release` to be created. |
| "createTime": "A String", # Time the release was created. |
| # @OutputOnly |
| "name": "A String", # Resource name for the `Release`. |
| # |
| # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2` |
| # which affords developers a great deal of flexibility in mapping the name |
| # to the style that best fits their existing development practices. For |
| # example, a name could refer to an environment, an app, a version, or some |
| # combination of three. |
| # |
| # In the table below, for the project name `projects/foo`, the following |
| # relative release paths show how flat and structured names might be chosen |
| # to match a desired development / deployment strategy. |
| # |
| # Use Case | Flat Name | Structured Name |
| # -------------|---------------------|---------------- |
| # Environments | releases/qa | releases/qa |
| # Apps | releases/app1_qa | releases/app1/qa |
| # Versions | releases/app1_v2_qa | releases/app1/v2/qa |
| # |
| # The delimiter between the release name path elements can be almost anything |
| # and it should work equally well with the release name list filter, but in |
| # many ways the structured paths provide a clearer picture of the |
| # relationship between `Release` instances. |
| # |
| # Format: `projects/{project_id}/releases/{release_id}` |
| }</pre> |
| </div> |
| |
| </body></html> |
