If we are making REST calls from a browser that does not support some of the above methods,
Firebase supports the X-HTTP-Method-Override header.

Let's start by saving some user data to our Firebase database. We'll store each user by a unique
username, and we'll also store their full name and date of birth. Since each user will have a
unique username, it makes sense to use PUT here instead of POST since
we already have the key and don't need to create one.

Using PUT, we can write a string, number, boolean, array or any JSON object to
our Firebase database. In this case we'll pass it an object:

When a JSON object is saved to the database, the object properties are automatically
mapped to child locations in a nested fashion. If we navigate to
the
newly created node, we'll see the value "Alan Turing". We can also save data directly to a
child location:

A successful request will be indicated by a 200 OK HTTP status code, and the
response will contain the data we wrote to the database. The first example will only
trigger one event on clients that are watching the data, whereas the second example will trigger
two. It is important to note that if data already existed at the users path, the first approach
would overwrite it, but the second method would only modify the value of each separate child
node while leaving other children unchanged. PUT is equivalent to
set() in our JavaScript SDK.

Using PUT will overwrite the data at the specified location, including any
child nodes.

Updating Data with PATCH

Using a PATCH request, we can update specific children at a location without
overwriting existing data. Let's add Turing's nickname to his user data with a PATCH
request:

The above request will write nickname to our alanisawesome object
without deleting the name or birthday children. Note that if we had
issued a PUT request here instead, name and birthday
would have been deleted since they were not included in the request. The data in our Firebase
database now looks like this:

A successful request will be indicated by a 200 OK HTTP status code, and the
response will contain the updated data written to the database.

Firebase also supports multi-path updates. This means that PATCH can now update values at multiple locations in your Firebase database at the same time, a powerful feature which allows helps you denormalize your data. Using multi-path updates, we can add nicknames to both Alan and Grace at the same time:

Saving Lists of Data

To generate a unique, timestamp-based key for every child added to a Firebase database reference
we can send a POST request. For our users path, it made sense to
define our own keys since each user has a unique username. But when users add blog posts to the
app, we'll use a POST request to auto-generate a key for each blog post:

Notice that the key -JSOpn9ZC54A4P4RoqVa was automatically generated for us because
we used a POST request. A successful request will be indicated by a 200 OK
HTTP status code, and the response will contain the key name of the new data that was added:

{"name":"-JSOpn9ZC54A4P4RoqVa"}

Interested in learning more about how push IDs are generated? Check out
this blog post.

Removing Data

To remove data from the database, we can send a DELETE request with the
URL of the path from which we'd like to delete data. The following would delete Alan from our
users path:

A successful DELETE request will be indicated by a 200 OK HTTP status code with a response containing JSON null.

URI Parameters

The REST API accepts the following URI parameters when writing data to the database:

auth

The auth request parameter allows access to data protected by
Security and Firebase Rules, and is
supported by all request types. The argument can either be our Firebase app secret or an
authentication token, which we'll cover in the user authorization
section. In the following example we send a POST request with an
auth parameter, where CREDENTIAL is either our Firebase app secret or
an authentication token:

If the token debug flag is set, debug information can be found in
the X-Firebase-Auth-Debug header of the response.

print

The print parameter lets us specify the format of our response from the
database. Adding print=pretty to our request will return the data in a
human-readable format. print=pretty is supported by GET,
PUT, POST, PATCH, and DELETE requests.

To suppress the output from the server when writing data, we can add
print=silent to our request. The resulting response will be empty and indicated by
a 204 No Content HTTP status code. print=silent is supported by
GET, PUT, POST, and PATCH requests.

Writing Server Values

Server values can be written at a location using a placeholder value, which is an object with a
single ".sv" key. The value for that key is the type of server value we wish to set.
For example, to set a timestamp when a user is created we could do the following:

"timestamp" is the only supported server value, and is the time since the UNIX
epoch in milliseconds.

Improving Write Performance

If we're writing large amounts of data to the database, we can use the
print=silent parameter to improve our write performance and decrease bandwidth
usage. In the normal write behavior, the server responds with the JSON data that was written.
When print=silent is specified, the server immediately
closes the connection once the data is received, reducing bandwidth usage.

In cases where we're making many requests to the database, we can re-use the HTTPS
connection by sending a Keep-Alive request in the HTTP header.

Error Conditions

The REST API will return error codes under these circumstances:

404 Not Found

A request made over HTTP instead of HTTPS

400 Bad Request

Unable to parse PUT or POST data
Missing PUT or POST data
Attempting to PUT or POST data which is too large
A REST API call that contains invalid child names as part of the path