Firebase 将于 5 月 14 日重返 Google I/O 大会！立即报名。

Ta strona została przetłumaczona przez Cloud Translation API.

Wdróż w swojej witrynie za pomocą interfejsu API REST Hostingu

Interfejs API REST Firebase Hosting umożliwia programowe i konfigurowalne wdrożenia w witrynach hostowanych przez Firebase. Użyj tego interfejsu API REST, aby wdrożyć nową lub zaktualizowaną zawartość i konfigurację hostingu.

Alternatywnie do używania interfejsu wiersza polecenia Firebase do wdrożeń możesz użyć interfejsu API REST Firebase Hosting, aby programowo utworzyć nową version zasobów dla swojej witryny, przesłać pliki do wersji, a następnie wdrożyć wersję w swojej witrynie.

Na przykład za pomocą interfejsu API REST Firebase Hosting możesz:

Zaplanuj wdrażanie. Korzystając z interfejsu API REST w połączeniu z zadaniem cron, możesz regularnie zmieniać zawartość hostowaną w Firebase (na przykład w celu wdrożenia specjalnej wersji treści związanej ze świętami lub wydarzeniami).
Integracja z narzędziami programistycznymi. Możesz utworzyć w swoim narzędziu opcję wdrażania projektów aplikacji internetowych w Hostingu Firebase za pomocą jednego kliknięcia (na przykład klikając przycisk wdrażania w środowisku IDE).
Automatyzuj wdrażanie, gdy generowana jest zawartość statyczna. Gdy proces programowo generuje zawartość statyczną (na przykład treść generowaną przez użytkowników, taką jak wiki lub artykuł z wiadomościami), można wdrożyć wygenerowaną treść jako pliki statyczne, zamiast udostępniać je dynamicznie. Oszczędza to kosztowną moc obliczeniową i udostępnia pliki w bardziej skalowalny sposób.

W tym przewodniku opisano najpierw sposób włączania, uwierzytelniania i autoryzacji interfejsu API. Następnie w tym przewodniku omówiono przykład tworzenia wersji Firebase Hosting, przesyłania wymaganych plików do tej wersji, a następnie wdrażania wersji.

Możesz także dowiedzieć się więcej o tym API REST w pełnej dokumentacji referencyjnej API REST Hostingu .

Zanim zaczniesz: Włącz interfejs API REST

Musisz włączyć interfejs API REST Firebase Hosting w konsoli Google API:

Otwórz stronę Firebase Hosting API w konsoli Google API.
Po wyświetleniu monitu wybierz projekt Firebase.
Uwaga: każdemu projektowi Firebase odpowiada projekt w konsoli Google API.
Kliknij Włącz na stronie Firebase Hosting API.

Krok 1: Uzyskaj token dostępu do uwierzytelniania i autoryzacji żądań API

Projekty Firebase obsługują konta usług Google, których możesz używać do wywoływania interfejsów API serwera Firebase z serwera aplikacji lub zaufanego środowiska. Jeśli tworzysz kod lokalnie lub wdrażasz aplikację lokalnie, możesz użyć poświadczeń uzyskanych za pośrednictwem tego konta usługi, aby autoryzować żądania serwera.

Aby uwierzytelnić konto usługi i autoryzować je do dostępu do usług Firebase, musisz wygenerować plik klucza prywatnego w formacie JSON.

Aby wygenerować plik klucza prywatnego dla swojego konta usługi:

W konsoli Firebase otwórz Ustawienia > Konta usług .
Kliknij opcję Wygeneruj nowy klucz prywatny , a następnie potwierdź, klikając opcję Wygeneruj klucz .
Bezpiecznie przechowuj plik JSON zawierający klucz.

Użyj danych uwierzytelniających Firebase razem z biblioteką Google Auth dla preferowanego języka, aby pobrać krótkotrwały token dostępu OAuth 2.0:

węzeł.js

const {google} = require('googleapis');
function getAccessToken() {
  return new Promise(function(resolve, reject) {
    var key = require('./service-account.json');
    var jwtClient = new google.auth.JWT(
      key.client_email,
      null,
      key.private_key,
      SCOPES,
      null
    );
    jwtClient.authorize(function(err, tokens) {
      if (err) {
        reject(err);
        return;
      }
      resolve(tokens.access_token);
    });
  });
}

W tym przykładzie biblioteka klienta API Google uwierzytelnia żądanie za pomocą tokena sieciowego JSON, czyli JWT. Aby uzyskać więcej informacji, zobacz tokeny internetowe JSON .

Pyton

def _get_access_token():
  """Retrieve a valid access token that can be used to authorize requests.

  :return: Access token.
  """
  credentials = ServiceAccountCredentials.from_json_keyfile_name(
      'service-account.json', SCOPES)
  access_token_info = credentials.get_access_token()
  return access_token_info.access_token

Jawa

private static String getAccessToken() throws IOException {
  GoogleCredential googleCredential = GoogleCredential
      .fromStream(new FileInputStream("service-account.json"))
      .createScoped(Arrays.asList(SCOPES));
  googleCredential.refreshToken();
  return googleCredential.getAccessToken();
}

Po wygaśnięciu tokenu dostępu metoda odświeżania tokenu jest wywoływana automatycznie w celu pobrania zaktualizowanego tokenu dostępu.

Krok 2: Upewnij się, że Twój projekt ma domyślną witrynę hostingową

Przed pierwszym wdrożeniem w Firebase Hosting Twój projekt Firebase musi mieć domyślną SITE Hostingową .

Sprawdź, czy Twój projekt ma już domyślną witrynę hostingową, wywołując punkt końcowy sites.list .
Na przykład:
polecenie cURL
```
curl -H "Content-Type: application/json" \
       -H "Authorization: Bearer ACCESS_TOKEN" \

https://firebasehosting.googleapis.com/v1beta1/projects/PROJECT_ID/sites
```
Surowe żądanie HTTPS
```
Host: firebasehosting.googleapis.com

POST /v1beta1/projects/PROJECT_ID/sites HTTP/1.1
Authorization: Bearer ACCESS_TOKEN
Content-Type: application/json
```
- Jeśli jedna z witryn ma "type": "DEFAULT_SITE" , oznacza to, że Twój projekt ma już domyślną witrynę hostingową. Pomiń pozostałą część tego kroku i przejdź do następnego: Utwórz nową wersję swojej witryny .
- Jeśli otrzymasz pustą tablicę, nie masz domyślnej witryny hostingowej. Wykonaj pozostałą część tego kroku.
Wybierz SITE_ID dla domyślnej witryny hostingowej. Decydując się na ten SITE_ID , pamiętaj o następujących kwestiach:
- Ten SITE_ID służy do tworzenia domyślnych subdomen Firebase:
  SITE_ID .web.app i SITE_ID .firebaseapp.com .
- SITE_ID ma następujące wymagania:
  - Musi to być prawidłowa etykieta nazwy hosta, co oznacza, że nie może zawierać . , _ itp.
  - Musi mieć maksymalnie 30 znaków
  - Musi być globalnie unikalny w Firebase
Pamiętaj, że często zalecamy użycie identyfikatora projektu jako identyfikatora SITE_ID dla domyślnej witryny hostingowej. Dowiedz się, jak znaleźć ten identyfikator w artykule Omówienie projektów Firebase .
Utwórz domyślną witrynę hostingową, wywołując punkt końcowy sites.create , używając żądanego SITE_ID jako parametru siteId .
Na przykład:
polecenie cURL
```
curl -H "Content-Type: application/json" \
       -H "Authorization: Bearer ACCESS_TOKEN" \

https://firebasehosting.googleapis.com/v1beta1/projects/PROJECT_ID/sites?siteId=SITE_ID
```
Surowe żądanie HTTPS
```
Host: firebasehosting.googleapis.com

POST /v1beta1/projects/PROJECT_ID/sites?siteId=SITE_ID
Authorization: Bearer ACCESS_TOKEN
Content-Type: application/json
```
To wywołanie interfejsu API do sites.create zwraca następujący kod JSON:
```
{
  "name": "projects/PROJECT_ID/sites/SITE_ID",
  "defaultUrl": "https://SITE_ID.web.app",
  "type": "DEFAULT_SITE"
}
```
Jeśli zdecydujesz się użyć identyfikatora projektu jako SITE_ID , zwróć uwagę na następujące kwestie:
W rzadkich przypadkach identyfikator Twojego projektu został już wykorzystany przez inny projekt do utworzenia witryny hostingowej. W takich przypadkach wywołanie sites.create zwraca komunikat o błędzie 400 z informacją, że podany SITE_ID jest reserved by another project . Aby rozwiązać ten błąd, spróbuj ponownie wywołać sites.create , używając ciągu sugerowanego w komunikacie o błędzie lub innego ciągu, aż wywołanie się powiedzie.

Krok 3: Utwórz nową wersję swojej witryny

Twoje pierwsze wywołanie interfejsu API polega na utworzeniu nowej Version witryny. W dalszej części tego przewodnika prześlesz pliki do tej wersji, a następnie wdrożysz je w swojej witrynie.

Określ SITE_ID dla lokacji, w której chcesz wdrożyć.
Uwaga: w przypadku domyślnej witryny hostingowej SITE_ID to identyfikator projektu Firebase (który jest używany do tworzenia subdomen Firebase SITE_ID .web.app i SITE_ID .firebaseapp.com ).
Jeśli w projekcie Firebase utworzyłeś wiele witryn , upewnij się, że używasz SITE_ID witryny, w której chcesz wdrożyć.

Wywołaj punkt końcowyversions.create , używając w wywołaniu swojego SITE_ID .

(Opcjonalnie) W wywołaniu możesz także przekazać obiekt konfiguracyjny Firebase Hosting , łącznie z ustawieniem nagłówka, który buforuje wszystkie pliki przez określony czas.

Na przykład:

polecenie cURL

curl -H "Content-Type: application/json" \
       -H "Authorization: Bearer ACCESS_TOKEN" \
       -d '{
             "config": {
               "headers": [{
                 "glob": "**",
                 "headers": {
                   "Cache-Control": "max-age=1800"
                 }
               }]
             }
           }' \
https://firebasehosting.googleapis.com/v1beta1/sites/SITE_ID/versions

Surowe żądanie HTTPS

Host: firebasehosting.googleapis.com

POST /v1beta1/sites/SITE_ID/versions HTTP/1.1
Authorization: Bearer ACCESS_TOKEN
Content-Type: application/json
Content-Length: 134

{
  "config": {
    "headers": [{
      "glob": "**",
      "headers": {
        "Cache-Control": "max-age=1800"
      }
    }]
  }
}

To wywołanie API versions.create zwraca następujący kod JSON:

{
  "name": "sites/SITE_ID/versions/VERSION_ID",
  "status": "CREATED",
  "config": {
    "headers": [{
      "glob": "**",
      "headers": {
        "Cache-Control": "max-age=1800"
      }
    }]
  }
}

Ta odpowiedź zawiera unikalny identyfikator nowej wersji w formacie: sites/ SITE_ID /versions/ VERSION_ID . Będziesz potrzebować tego unikalnego identyfikatora w całym tym przewodniku, aby odnieść się do tej konkretnej wersji.

Krok 4: Określ listę plików, które chcesz wdrożyć

Teraz, gdy masz już identyfikator nowej wersji, musisz poinformować Firebase Hosting, które pliki chcesz ostatecznie wdrożyć w tej nowej wersji.

Należy pamiętać, że w Hostingu maksymalny rozmiar poszczególnych plików wynosi 2 GB.

Ten interfejs API wymaga identyfikacji plików za pomocą skrótu SHA256. Tak więc, zanim będziesz mógł wykonać wywołanie API, musisz najpierw obliczyć skrót dla każdego pliku statycznego, pakując pliki Gzipem, a następnie pobierając skrót SHA256 każdego nowo skompresowanego pliku.

Kontynuując nasz przykład, załóżmy, że chcesz wdrożyć trzy pliki w nowej wersji: file1 , file2 i file3 .

Spakuj pliki:
```
gzip file1 && gzip file2 && gzip file3
```
Masz teraz trzy skompresowane pliki file1.gz , file2.gz i file3.gz .

Uzyskaj skrót SHA256 każdego skompresowanego pliku:

cat file1.gz | openssl dgst -sha256

66d61f86bb684d0e35f94461c1f9cf4f07a4bb3407bfbd80e518bd44368ff8f4

cat file2.gz | openssl dgst -sha256

490423ebae5dcd6c2df695aea79f1f80555c62e535a2808c8115a6714863d083

cat file3.gz | openssl dgst -sha256

59cae17473d7dd339fe714f4c6c514ab4470757a4fe616dfdb4d81400addf315

Masz teraz trzy skróty SHA256 trzech skompresowanych plików.

Wyślij versions.populateFiles trzy skróty w żądaniu API do punktu końcowegoversions.populateFiles. Wypisz każdy skrót według żądanej ścieżki przesłanego pliku (w tym przykładzie /file1 , /file2 i /file3 ).

Na przykład:

polecenie cURL

$ curl -H "Content-Type: application/json" \
         -H "Authorization: Bearer ACCESS_TOKEN" \
         -d '{
               "files": {
                 "/file1": "66d61f86bb684d0e35f94461c1f9cf4f07a4bb3407bfbd80e518bd44368ff8f4",
                 "/file2": "490423ebae5dcd6c2df695aea79f1f80555c62e535a2808c8115a6714863d083",
                 "/file3": "59cae17473d7dd339fe714f4c6c514ab4470757a4fe616dfdb4d81400addf315"
               }
             }' \
https://firebasehosting.googleapis.com/v1beta1/sites/SITE_ID/versions/VERSION_ID:populateFiles

Surowe żądanie HTTPS

Host: firebasehosting.googleapis.com

POST /v1beta1/sites/SITE_ID/versions/VERSION_ID:populateFiles HTTP/1.1
Authorization: Bearer ACCESS_TOKEN
Content-Type: application/json
Content-Length: 181

{
  "files": {
    "/file1": "66d61f86bb684d0e35f94461c1f9cf4f07a4bb3407bfbd80e518bd44368ff8f4",
    "/file2": "490423ebae5dcd6c2df695aea79f1f80555c62e535a2808c8115a6714863d083",
    "/file3": "59cae17473d7dd339fe714f4c6c514ab4470757a4fe616dfdb4d81400addf315"
  }
}

To wywołanie interfejsu API versions.populateFiles zwraca następujący kod JSON:

{
  "uploadRequiredHashes": [
    "490423ebae5dcd6c2df695aea79f1f80555c62e535a2808c8115a6714863d083",
    "59cae17473d7dd339fe714f4c6c514ab4470757a4fe616dfdb4d81400addf315"
  ],
  "uploadUrl": "https://upload-firebasehosting.googleapis.com/upload/sites/SITE_ID/versions/VERSION_ID/files"
}

Ta odpowiedź zawiera:

Skrót każdego pliku , który należy przesłać. Na przykład w tym przykładzie file1 został już przesłany w poprzedniej wersji, więc jego skrót nie jest uwzględniony na liście uploadRequiredHashes .
Uwaga: niektórych plików w nowej wersji nie trzeba przesyłać, na przykład jeśli plik znajdował się już w poprzedniej wersji i nie został zmodyfikowany dla nowej wersji.
uploadUrl , który jest specyficzny dla nowej wersji.

W następnym kroku przesyłania dwóch nowych plików potrzebne będą skróty i uploadURL z odpowiedzi versions.populateFiles .

Krok 5: Prześlij wymagane pliki

Musisz osobno przesłać każdy wymagany plik (te pliki, które są wymienione w uploadRequiredHashes z versions.populateFiles w poprzednim kroku). Do przesyłania plików potrzebne będą skróty plików i uploadUrl z poprzedniego kroku.

Dołącz ukośnik i skrót pliku do uploadUrl , aby utworzyć adres URL specyficzny dla pliku w formacie: https://upload-firebasehosting.googleapis.com/upload/sites/ SITE_ID /versions/ VERSION_ID /files/ FILE_HASH .

Prześlij pojedynczo wszystkie wymagane pliki (w tym przykładzie tylko file2.gz i file3.gz ) pod adres URL specyficzny dla pliku, korzystając z serii żądań.

Na przykład, aby przesłać skompresowany file2.gz :

polecenie cURL

curl -H "Authorization: Bearer ACCESS_TOKEN" \
       -H "Content-Type: application/octet-stream" \
       --data-binary @./file2.gz \
https://upload-firebasehosting.googleapis.com/upload/sites/SITE_ID/versions/VERSION_ID/files/FILE_HASH

Surowe żądanie HTTPS

Host: upload-firebasehosting.googleapis.com

POST /upload/sites/SITE_ID/versions/VERSION_ID/files/FILE_HASH HTTP/1.1
Authorization: Bearer ACCESS_TOKEN
Content-Type: application/octet-stream
Content-Length: 500

content-of-file2.gz

Pomyślne przesyłanie zwraca odpowiedź HTTPS 200 OK .

Krok 6: Zaktualizuj status wersji na SKOŃCZONA

Po przesłaniu wszystkich plików wymienionych w odpowiedzi versions.populateFiles możesz zaktualizować status swojej wersji na FINALIZED .

Wywołaj punkt końcowy versions.patch z polem status w żądaniu API ustawionym na FINALIZED .

Na przykład:

polecenie cURL

curl -H "Content-Type: application/json" \
       -H "Authorization: Bearer ACCESS_TOKEN" \
       -X PATCH \
       -d '{"status": "FINALIZED"}' \
https://firebasehosting.googleapis.com/v1beta1/sites/SITE_ID/versions/VERSION_ID?update_mask=status

Surowe żądanie HTTPS

Host: firebasehosting.googleapis.com

PATCH /v1beta1/sites/SITE_ID/versions/VERSION_ID?update_mask=status HTTP/1.1
Authorization: Bearer ACCESS_TOKEN
Content-Type: application/json
Content-Length: 23

{"status": "FINALIZED"}

To wywołanie interfejsu API versions.patch zwraca następujący kod JSON. Sprawdź, czy status został zaktualizowany do FINALIZED .

{
  "name": "sites/SITE_ID/versions/VERSION_ID",
  "status": "FINALIZED",
  "config": {
    "headers": [{
      "glob": "**",
      "headers": {"Cache-Control": "max-age=1800"}
    }]
  },
  "createTime": "2018-12-02T13:41:56.905743Z",
  "createUser": {
    "email": "SERVICE_ACCOUNT_EMAIL@SITE_ID.iam.gserviceaccount.com"
  },
  "finalizeTime": "2018-12-02T14:56:13.047423Z",
  "finalizeUser": {
    "email": "USER_EMAIL@DOMAIN.tld"
  },
  "fileCount": "5",
  "versionBytes": "114951"
}

Krok 7: Zwolnij wersję do wdrożenia

Teraz, gdy masz już ostateczną wersję, udostępnij ją do wdrożenia. Na tym etapie musisz utworzyć Release swojej wersji zawierającą konfigurację hostingu i wszystkie pliki zawartości nowej wersji.

Wywołaj punkt końcowy releases.create , aby utworzyć wersję.

Na przykład:

polecenie cURL

curl -H "Authorization: Bearer ACCESS_TOKEN" \
       -X POST
https://firebasehosting.googleapis.com/v1beta1/sites/SITE_ID/releases?versionName=sites/SITE_ID/versions/VERSION_ID

Surowe żądanie HTTPS

Host: firebasehosting.googleapis.com

POST /v1beta1/sites/SITE_ID/releases?versionName=sites/SITE_ID/versions/VERSION_ID HTTP/1.1
Authorization: Bearer ACCESS_TOKEN

To wywołanie API releases.create zwraca następujący kod JSON:

{
  "name": "sites/SITE_ID/releases/RELEASE_ID",
  "version": {
    "name": "sites/SITE_ID/versions/VERSION_ID",
    "status": "FINALIZED",
    "config": {
    "headers": [{
      "glob": "**",
      "headers": {"Cache-Control": "max-age=1800"}
    }]
  }
  },
  "type": "DEPLOY",
  "releaseTime": "2018-12-02T15:14:37Z"
}

Konfiguracja hostingu i wszystkie pliki nowej wersji powinny zostać teraz wdrożone w Twojej witrynie, a dostęp do plików będzie możliwy za pomocą adresów URL:

https:// SITE_ID .web.app/file1
https:// SITE_ID .web.app/file2
https:// SITE_ID .web.app/file3

Pliki te są również dostępne pod adresami URL powiązanymi z Twoją domeną SITE_ID .firebaseapp.com .

Możesz także zobaczyć swoją nową wersję na liście w panelu hostingu konsoli Firebase.