如果您在构建服务器端渲染的 Angular 或 Next.js 应用，不妨试试我们新一代的 Firebase App Hosting，这是一款适用于现代 Web 框架的全栈解决方案。

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

Wdróż w swojej witrynie przy użyciu interfejsu Hosting REST API

Firebase HostingInterfejs API REST umożliwia programowe i dostosowywane wdrażanie w witrynach hostowanych w Firebase. Użyj tego interfejsu API REST, aby wdrożyć nowe lub zaktualizowane treści i konfigurację Hosting.

Zamiast używać do wdrażania interfejsu wiersza poleceń Firebase, możesz użyć interfejsu API REST Firebase Hosting, aby programowo utworzyć nową version zasobów dla witryny, przesłać pliki do wersji, a następnie wdrożyć ją w witrynie.

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

Planuj wdrożenia. Korzystając z interfejsu REST API w połączeniu z zadaniem cron, możesz regularnie zmieniać treści hostowane w Firebase (np. wdrażać specjalną wersję treści związaną ze świętami lub wydarzeniami).
Integracja z narzędziami dla programistów Możesz utworzyć w narzędziu opcję wdrażania projektów aplikacji internetowych w Firebase Hosting za pomocą jednego kliknięcia (np. kliknięcia przycisku wdrażania w środowisku IDE).
Automatyzacja wdrażania po wygenerowaniu treści statycznych. Gdy proces generuje statyczne treści programowo (np. treści generowane przez użytkowników, takie jak wiki lub artykuł), możesz wdrożyć wygenerowane treści jako pliki statyczne, zamiast wyświetlać je dynamicznie. Pozwala to zaoszczędzić kosztowną moc obliczeniową i skalowalnie udostępniać pliki.

W tym przewodniku najpierw opisujemy, jak włączyć interfejs API, uwierzytelnić się i autoryzować. Następnie w tym przewodniku znajdziesz przykład tworzenia Firebase Hostingwersji, przesyłania do niej wymaganych plików i wdrażania jej.

Więcej informacji o tym interfejsie API REST znajdziesz w pełnej Hosting dokumentacji interfejsu API REST.

Zanim zaczniesz: włączanie interfejsu API REST

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

Otwórz stronę interfejsu API Firebase Hosting w konsoli interfejsów API Google.
Gdy pojawi się taka prośba, wybierz projekt Firebase.

Uwaga: każdy projekt Firebase ma odpowiedni projekt w Konsoli interfejsów API Google.
Na stronie interfejsu API Firebase Hosting kliknij Włącz.

Krok 1. Uzyskiwanie tokena dostępu do uwierzytelniania i autoryzowania żądań do interfejsu API

Projekty Firebase obsługują konta usługi 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ć danych logowania uzyskanych za pomocą tego konta usługi, aby autoryzować żądania serwera.

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

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

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

Użyj danych logowania Firebase wraz z biblioteką Google Auth Library w preferowanym języku, aby pobrać krótkotrwały token dostępu OAuth 2.0:

node.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 interfejsu Google API uwierzytelnia żądanie za pomocą tokena sieciowego JSON (JWT). Więcej informacji znajdziesz w artykule Tokeny sieciowe JSON.

Python

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

Java

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 tokena dostępu automatycznie wywoływana jest metoda odświeżania tokena, aby pobrać zaktualizowany token dostępu.

Krok 2. Sprawdź, czy Twój projekt ma domyślną witrynę Hosting

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

Sprawdź, czy w projekcie jest już domyślna witryna Hosting, wywołując punkt końcowy sites.list.

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 ikonę "type": "DEFAULT_SITE", oznacza to, że Twój projekt ma już domyślną witrynę Hosting. Pomiń pozostałą część tego kroku i przejdź do następnego: Tworzenie nowej wersji witryny.
- Jeśli otrzymasz pustą tablicę, oznacza to, że nie masz domyślnej witryny Hosting. Wykonaj pozostałą część tego kroku.
Określ SITE_ID dla domyślnej Hosting witryny. Pamiętaj o tych kwestiach, gdy będziesz podejmować decyzję dotyczącą tego SITE_ID:
- Ta SITE_IDnazwa jest używana do tworzenia domyślnych subdomen Firebase:
  SITE_ID.web.app i SITE_ID.firebaseapp.com.
- SITE_ID musi spełniać te wymagania:
  - Musi to być prawidłowa etykieta nazwy hosta, co oznacza, że nie może zawierać znaków ., _ itp.
  - Maksymalna liczba znaków to 30
  - Musi być globalnie niepowtarzalna w Firebase.
Pamiętaj, że często zalecamy używanie identyfikatora projektu jako SITE_ID w przypadku domyślnej witryny Hosting. Dowiedz się, jak znaleźć ten identyfikator w artykule Projekty Firebase.
Utwórz domyślną witrynę Hosting, wywołując punkt końcowy sites.create za pomocą wybranego parametru SITE_ID jako parametru siteId.

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 sites.create zwraca ten 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, pamiętaj o tych kwestiach:
W rzadkich przypadkach Twój identyfikator projektu został już użyty w innym projekcie do utworzenia witryny Hosting. W takich przypadkach wywołanie funkcji sites.create zwraca komunikat o błędzie 400, który informuje, że podany parametr SITE_ID jest reserved by another project. Aby rozwiązać ten problem, spróbuj ponownie zadzwonić sites.create, używając sugerowanego ciągu znaków w komunikacie o błędzie lub innego ciągu znaków, aż połączenie się powiedzie.

Krok 3. Utwórz nową wersję witryny

Pierwsze wywołanie interfejsu API polega na utworzeniu nowego Version dla Twojej witryny. W dalszej części tego przewodnika prześlesz pliki do tej wersji, a następnie wdrożysz ją w swojej witrynie.

Określ SITE_ID witryny, w której chcesz wdrożyć aplikację.

Uwaga: w przypadku domyślnej witryny Hosting element 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 masz utworzonych kilka witryn, upewnij się, że używasz elementu SITE_ID witryny, w której chcesz wdrożyć zmiany.

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

(Opcjonalnie) Możesz też przekazać w wywołaniu Firebase Hosting obiekt konfiguracji, w tym ustawić nagłówek, który buforuje wszystkie pliki przez określony czas.

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 interfejsu API versions.create zwraca ten 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. Ten unikalny identyfikator będzie potrzebny w całym przewodniku, aby odwoływać 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 określić, Firebase Hostingktóre pliki chcesz ostatecznie wdrożyć w tej nowej wersji.

Pamiętaj, że maksymalny rozmiar pojedynczego pliku w Hosting to 2 GB.

Ten interfejs API wymaga identyfikowania plików za pomocą skrótu SHA256. Zanim wywołasz interfejs API, musisz najpierw obliczyć skrót każdego pliku statycznego, kompresując pliki za pomocą gzip, a następnie obliczając skrót SHA256 każdego nowo skompresowanego pliku.

W naszym przykładzie załóżmy, że w nowej wersji chcesz wdrożyć 3 pliki: file1, file2 i file3.

Skompresuj pliki za pomocą gzip:
```
gzip file1 && gzip file2 && gzip file3
```
Masz teraz 3 skompresowane pliki: file1.gz, file2.gz i file3.gz.

Pobierz identyfikator 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 3 identyfikatory SHA256 3 skompresowanych plików.

Wyślij te 3 wartości skrótu w żądaniu API do punktu końcowego versions.populateFiles. Wymień poszczególne hasze według żądanej ścieżki przesłanego pliku (w tym przykładzie /file1, /file2 i /file3).

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

Nieprzetworzone żą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 ten kod JSON:

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

Odpowiedź zawiera:

Hash każdego pliku, który ma zostać przesłany. Na przykład w tym przykładzie plik file1 został już przesłany w poprzedniej wersji, więc jego hash nie jest uwzględniony na liście uploadRequiredHashes.

Uwaga: niektórych plików w nowej wersji nie trzeba przesyłać, np. jeśli plik był już w poprzedniej wersji i nie został zmodyfikowany w nowej wersji.
uploadUrl, która jest specyficzna dla nowej wersji.

W kolejnym kroku, aby przesłać 2 nowe pliki, potrzebujesz skrótów i uploadURL z odpowiedzi versions.populateFiles.

Krok 5. Prześlij wymagane pliki

Musisz przesłać każdy wymagany plik osobno (pliki wymienione w uploadRequiredHashes z odpowiedzi versions.populateFiles w poprzednim kroku). W przypadku tych przesłanych plików potrzebne będą hasze plików i uploadUrl z poprzedniego kroku.

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

Prześlij wszystkie wymagane pliki pojedynczo (w tym przykładzie tylko file2.gz i file3.gz) na adres URL konkretnego pliku za pomocą serii żądań.

Aby na przykład przesłać skompresowany plik 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

Nieprzetworzone żą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

Przesłanie zakończone powodzeniem zwraca odpowiedź HTTPS 200 OK.

Krok 6. Zmień stan wersji na FINALIZED

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

Wywołaj punkt końcowy versions.patch, ustawiając w żądaniu do interfejsu API pole status na wartość FINALIZED.

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

Nieprzetworzone żą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 ten plik JSON. Sprawdź, czy status zostało zaktualizowane do wersji 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. Wdróż wersję

Gdy wersja będzie gotowa, opublikuj ją, aby można było ją wdrożyć. W tym kroku musisz utworzyć Release swojej wersji, która zawiera konfigurację hostingu i wszystkie pliki treści dla nowej wersji.

Aby utworzyć wersję, wywołaj punkt końcowy releases.create.

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

Nieprzetworzone żą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 interfejsu API releases.create zwraca ten 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 być teraz wdrożone w Twojej witrynie. Możesz uzyskać dostęp do plików za pomocą adresów URL:

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

Te pliki są też dostępne pod adresami URL powiązanymi z Twoją domeną SITE_ID.firebaseapp.com.

Nowa wersja będzie też widoczna w Hostingpanelu w Firebasekonsoli.