Google używa technologii AI do tłumaczenia treści na Twój preferowany język. Tłumaczenia wygenerowane przez AI mogą zawierać błędy.

Publikowanie interfejsów API przy użyciu interfejsu Edge API

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info

W tej sekcji dowiesz się, jak używać interfejsu Edge API do tworzenia usług API, które można publikować w portalach dla deweloperów.

Tworzenie produktów interfejsu API za pomocą interfejsu API

Usługi API umożliwiają programistom rejestrowanie aplikacji korzystających z interfejsów API za pomocą kluczy interfejsu API i tokenów dostępu OAuth. Usługi API zostały zaprojektowane tak, aby umożliwić Ci „pakietowanie” zasobów interfejsu API, a następnie publikowanie tych pakietów w różnych grupach deweloperów. Możesz na przykład opublikować jeden zestaw zasobów interfejsu API dla deweloperów partnerskich, a inny pakiet dla deweloperów zewnętrznych. Usługi API umożliwiają dynamiczne łączenie interfejsów API bez konieczności wprowadzania w nich zmian. Dodatkową zaletą jest to, że dostęp dewelopera można „ulepszyć” i „obniżyć” bez konieczności uzyskiwania przez deweloperów nowych kluczy konsumenckich do aplikacji.

Aby utworzyć produkt interfejsu API za pomocą interfejsu API, wyślij żądanie POST do /organizations/{org_name}/apiproducts. Więcej informacji znajdziesz w dokumentacji API Create API Product.

Poniższe żądanie tworzy produkt interfejsu API o nazwie weather_free. Produkt interfejsu API zapewnia dostęp do wszystkich interfejsów API udostępnianych przez proxy interfejsu API o nazwie weatherapi, który jest wdrażany w środowisku test. Typ zatwierdzenia jest ustawiony na auto, co oznacza, że każda prośba o dostęp zostanie zatwierdzona.

curl -X POST https://api.enterprise.apigee.com/v1/organization/myorg/apiproducts \
-H "Content-Type:application/json" \
-d \
'{
  "approvalType": "auto",
  "displayName": "Free API Product",
  "name": "weather_free",
  "proxies": [ "weatherapi" ],
  "environments": [ "test" ]
}' \
-u email:password

Przykładowa odpowiedź:

{
  "apiResources" : [ ],
  "approvalType" : "auto",
  "attributes" : [ ],
  "createdAt" : 1362759663145,
  "createdBy" : "developer@apigee.com",
  "displayName" : "Free API Product",
  "environments" : [ "test" ],
  "lastModifiedAt" : 1362759663145,
  "lastModifiedBy" : "developer@apigee.com",
  "name" : "weather_free",
  "proxies" : [ "weatherapi" ],
  "scopes" : [ ]
}

Utworzony powyżej produkt interfejsu API realizuje najbardziej podstawowy scenariusz, czyli autoryzuje żądania do proxy interfejsu API w środowisku. Definiuje produkt API, który umożliwia autoryzowanej aplikacji dostęp do wszystkich zasobów API, do których uzyskuje się dostęp za pomocą proxy interfejsu API działającego w środowisku testowym. Produkty interfejsu API udostępniają dodatkowe ustawienia konfiguracji, które umożliwiają dostosowanie kontroli dostępu do interfejsów API dla różnych grup deweloperów. Możesz na przykład utworzyć 2 usługi API, które zapewniają dostęp do różnych proxy interfejsów API. Możesz też utworzyć 2 produkty API, które zapewniają dostęp do tych samych serwerów proxy API, ale mają różne powiązane ustawienia limitu.

Ustawienia konfiguracji usługi API

Usługi API udostępniają te opcje konfiguracji:

Nazwa	Opis	Domyślny	Wymagany?
`apiResources`	Rozdzielona przecinkami lista identyfikatorów URI lub ścieżek zasobów „powiązanych” z produktem interfejsu API. Domyślnie ścieżki zasobów są mapowane ze zmiennej `proxy.pathsuffix`. Sufiks ścieżki proxy jest zdefiniowany jako fragment URI następujący po podstawowej ścieżce ProxyEndpoint. Na przykład w przykładowym produkcie API poniżej element `apiResources` ma wartość `/forecastrss`. Ścieżka podstawowa zdefiniowana dla tego proxy interfejsu API to `/weather`, co oznacza, że ten produkt interfejsu API zezwala tylko na żądania wysyłane do `/weather/forecastrss`. Możesz wybrać konkretną ścieżkę lub wszystkie ścieżki podrzędne za pomocą symbolu wieloznacznego. Symbole wieloznaczne (/** i /) są obsługiwane. Symbol wieloznaczny w postaci podwójnej gwiazdki oznacza, że uwzględnione są wszystkie podrzędne identyfikatory URI. Pojedyncza gwiazdka oznacza, że uwzględniane są tylko identyfikatory URI o 1 poziom niżej. Domyślnie '/' obsługuje te same zasoby co '/*', a także ścieżkę podstawową zdefiniowaną przez proxy interfejsu API. Jeśli na przykład ścieżka podstawowa proxy interfejsu API to /v1/weatherapikey, produkt API obsługuje żądania do /v1/weatherapikey i wszystkich podrzędnych identyfikatorów URI, takich jak /v1/weatherapikey/forecastrss, /v1/weatherapikey/region/CA itd. Informacje o zmianie domyślnego działania znajdziesz w artykule Zarządzanie produktami interfejsu API.	Nie dotyczy	Nie
`approvalType`	Określa, w jaki sposób klucze interfejsu API są zatwierdzane w celu uzyskania dostępu do interfejsów API zdefiniowanych przez produkt API. Jeśli ustawisz wartość `manual`, klucz wygenerowany dla aplikacji będzie w stanie „oczekujący”. Takie klucze nie będą działać, dopóki nie zostaną wyraźnie zatwierdzone. Jeśli ustawisz wartość `auto`, wszystkie klucze zostaną wygenerowane w stanie „zatwierdzony” i będą od razu działać. (`auto` jest zwykle używany do zapewniania dostępu do bezpłatnych lub próbnych wersji interfejsów API, które oferują ograniczony limit lub możliwości).	Nie dotyczy	Tak
`attributes`	Tablica atrybutów, których można użyć do rozszerzenia domyślnego profilu produktu API o metadane specyficzne dla klienta. Użyj tej właściwości, aby określić poziom dostępu do produktu interfejsu API jako publiczny, prywatny lub wewnętrzny. Na przykład: "attributes": [ { "name": "access", "value": "public" }, { "name": "foo", "value": "foo" }, { "name": "bar", "value": "bar" } ]	Nie dotyczy	Nie
`scopes`	Lista rozdzielonych przecinkami zakresów OAuth, które są weryfikowane w czasie działania. (Apigee Edge sprawdza, czy zakresy w dowolnym przedstawionym tokenie dostępu są zgodne z zakresem ustawionym w usłudze API).	Nie dotyczy	Nie
`proxies`	Nazwane proxy interfejsów API, z którymi powiązana jest ta usługa API. Określając serwery proxy, możesz powiązać zasoby w produkcie API z konkretnymi serwerami proxy interfejsu API, uniemożliwiając programistom dostęp do tych zasobów za pomocą innych serwerów proxy interfejsu API.	Nie dotyczy	Nie. Jeśli nie jest zdefiniowany, `apiResources` należy go zdefiniować w sposób jawny (patrz informacje o `apiResources` powyżej), a zmienną `flow.resource.name` należy ustawić w zasadach AssignMessage.
`environments`	Nazwane środowiska (np. „test” lub „prod”), z którymi powiązany jest ten produkt API. Określając co najmniej jedno środowisko, możesz powiązać zasoby wymienione w produkcie API z konkretnym środowiskiem, uniemożliwiając programistom dostęp do tych zasobów za pomocą proxy interfejsu API w innym środowisku. To ustawienie służy na przykład do uniemożliwienia dostępu do zasobów powiązanych z proxy interfejsu API w środowisku „prod” przez proxy interfejsu API wdrożone w środowisku „test”.	Nie dotyczy	Nie. Jeśli nie jest zdefiniowana, zmienna `apiResources` musi być zdefiniowana w zasadzie AssignMessage, a zmienna `flow.resource.name` musi być w niej ustawiona.
`quota`	Liczba żądań dozwolonych w przypadku każdej aplikacji w określonym przedziale czasu.	Nie dotyczy	Nie
`quotaInterval`	Liczba jednostek czasu, w których są oceniane limity	Nie dotyczy	Nie
`quotaTimeUnit`	Jednostka czasu (minuta, godzina, dzień lub miesiąc), w której są zliczane limity.	Nie dotyczy	Nie

Poniżej znajdziesz bardziej szczegółowy przykład tworzenia produktu API.

curl -X POST  https://api.enterprise.apigee.com/v1/o/{org_name}/apiproducts \
-H "Content-Type:application/json" -d \
'{
  "apiResources": [ "/forecastrss" ],
  "approvalType": "auto", 
  "attributes":
    [ {"name": "access", "value": "public"} ],
  "description": "Free API Product",
  "displayName": "Free API Product",
  "name": "weather_free",
  "scopes": [],
  "proxies": [ "weatherapi" ],
  "environments": [ "test" ],
  "quota": "10",
  "quotaInterval": "2",
  "quotaTimeUnit": "hour" }' \
-u email:password

Przykładowa odpowiedź

{
  "apiResources" : [ "/forecastrss" ],
  "approvalType" : "auto",
  "attributes" : [ {
    "name" : "access",
    "value" : "public"
  },
  "createdAt" : 1344454200828,
  "createdBy" : "admin@apigee.com",
  "description" : "Free API Product",
  "displayName" : "Free API Product",
  "lastModifiedAt" : 1344454200828,
  "lastModifiedBy" : "admin@apigee.com",
  "name" : "weather_free",
  "scopes" : [ ],
  "proxies": [ {'weatherapi'} ],
  "environments": [ {'test'} ],
  "quota": "10",
  "quotaInterval": "1",
  "quotaTimeUnit": "hour"}'
}

Zakresy

Zakres to pojęcie zaczerpnięte z OAuth, które w przybliżeniu odpowiada pojęciu „uprawnienia”. W Apigee Edge zakresy są całkowicie opcjonalne. Zakresów możesz używać do bardziej szczegółowej autoryzacji. Każdy klucz klienta wydany aplikacji jest powiązany z „zakresem głównym”. Zakres główny to zbiór wszystkich zakresów we wszystkich produktach interfejsu API, w których przypadku aplikacja została zatwierdzona. W przypadku aplikacji, które mogą korzystać z wielu usług API, zakres główny jest sumą wszystkich zakresów zdefiniowanych w usługach API, dla których klucz klienta został zatwierdzony.

Wyświetlanie usług API

Aby wyświetlić produkty interfejsu API utworzone dla organizacji za pomocą interfejsu API, zapoznaj się z tymi sekcjami:

Wyświetlanie usług API (objętych monetyzacją)
Domyślnie wyświetlane są tylko usługi API generujące przychód (czyli usługi API z co najmniej 1 opublikowanym abonamentem). Aby wyświetlić wszystkie produkty interfejsu API, ustaw parametr zapytania monetized na false. Jest to równoznaczne z wysłaniem żądania GET do interfejsu API produktów List API, który nie generuje przychodów:https://api.enterprise.apigee.com/v1/organizations/{org_name}/apiproducts?expand=true
Wyświetlanie usług API (bez możliwości zarabiania)
Wyświetlanie kwalifikujących się produktów API dla dewelopera
Wyświetlanie kwalifikujących się usług API dla firmy

Poniżej znajdziesz przykład wyświetlania produktów interfejsu API za pomocą interfejsu API:

curl -X GET "https://ext.apiexchange.org/v1/mint/organizations/{org_name}/products?monetized=true" \
  -H "Accept:application/json" \
  -u email:password

Odpowiedź powinna wyglądać mniej więcej tak (pokazano tylko jej część):

{
  "product" : [ {
    "customAtt1Name" : "user",
    "customAtt2Name" : "response size",
    "customAtt3Name" : "content-length",
    "description" : "payment api product",
    "displayName" : "payment",
    "id" : "payment",
    "name" : "payment",
    "organization" : {
      ...
    },
    "pricePoints" : [ ],
    "status" : "CREATED",
    "transactionSuccessCriteria" : "status == 'SUCCESS'"
  }, {
    "customAtt1Name" : "user",
    "customAtt2Name" : "response size",
    "customAtt3Name" : "content-length",
    "description" : "messaging api product",
    "displayName" : "messaging",
    "id" : "messaging",
    "name" : "messaging",
    "organization" : ...
    },
    "pricePoints" : [ ],
    "status" : "CREATED",
    "transactionSuccessCriteria" : "status == 'SUCCESS'"
  } ],
  "totalRecords" : 2
}

Rejestrowanie deweloperów za pomocą interfejsu API

Wszystkie aplikacje należą do deweloperów lub firm. Aby utworzyć aplikację, musisz najpierw zarejestrować dewelopera lub firmę.

Deweloperzy są rejestrowani w organizacji przez utworzenie profilu. Pamiętaj, że adres e-mail dewelopera podany w profilu jest używany jako unikalny klucz dewelopera w całym Apigee Edge.

Aby obsługiwać zarabianie, podczas tworzenia lub edytowania kont deweloperów musisz zdefiniować atrybuty zarabiania. Możesz też zdefiniować inne dowolne atrybuty do użycia w niestandardowych analizach, egzekwowaniu zasad niestandardowych itp. Te dowolne atrybuty nie będą interpretowane przez Apigee Edge.

Na przykład to żądanie rejestruje profil dewelopera, którego adres e-mail to ntesla@theremin.com, i określa podzbiór atrybutów zarabiania za pomocą interfejsu Create developer API:

$ curl -H "Content-type:application/json" -X POST -d \
'{"email" : "ntesla@theremin.com", 
  "firstName" : "Nikola", 
  "lastName" : "Tesla", 
  "userName" : "theremin", 
  "attributes" : [ 
  { 
    "name" : "project_type", 
    "value" : "public"
  },
  {    
   "name": "MINT_BILLING_TYPE",
   "value": "POSTPAID"
  },
  {
   "name": "MINT_DEVELOPER_ADDRESS",
   "value": "{\"address1\":\"Dev One Address\",\"city\":\"Pleasanton\",\"country\":\"US\",\"isPrimary\":true,\"state\":\"CA\",\"zip\":\"94588\"}"
  },
  {
   "name": "MINT_DEVELOPER_TYPE",
   "value": "TRUSTED"
  },
  {    
   "name": "MINT_HAS_SELF_BILLING,
   "value": "FALSE"
  },
  {
   "name" : "MINT_SUPPORTED_CURRENCY",
   "value" : "usd"
  }
 ] 
}' \
https://api.enterprise.apigee.com/v1/o/{org_name}/developers \
-u email:password

Przykładowa odpowiedź

{
          "email" : "ntesla@theremin.com",
          "firstName" : "Nikola",
          "lastName" : "Tesla",
          "userName" : "theremin",
          "organizationName" : "{org_name}",
          "status" : "active",
          "attributes" : [ 
          {
            "name" : "project_type",
            "value" : "public"
          },
          {    
             "name": "MINT_BILLING_TYPE",
             "value": "POSTPAID"
          },
          {
             "name": "MINT_DEVELOPER_ADDRESS",
             "value": "{\"address1\":\"Dev One Address\",\"city\":\"Pleasanton\",\"country\":\"US\",\"isPrimary\":true,\"state\":\"CA\",\"zip\":\"94588\"}"
          },
          {
             "name": "MINT_DEVELOPER_TYPE",
             "value": "TRUSTED"
          },
          {    
             "name": "MINT_HAS_SELF_BILLING,
             "value": "FALSE"
          },
          {
             "name" : "MINT_SUPPORTED_CURRENCY",
             "value" : "usd"
          } 
          ],
          "createdAt" : 1343189787717,
          "createdBy" : "admin@apigee.com",
          "lastModifiedAt" : 1343189787717,
          "lastModifiedBy" : "admin@apigee.com"
        }

Rejestrowanie aplikacji deweloperskich za pomocą interfejsu API

Każda aplikacja zarejestrowana w Apigee Edge jest powiązana z deweloperem i produktem API. Gdy aplikacja jest rejestrowana w imieniu dewelopera, Apigee Edge generuje „dane logowania” (parę klucza i klucza tajnego klienta), które identyfikują aplikację. Aplikacja musi następnie przekazywać te dane logowania w ramach każdego żądania do produktu API powiązanego z aplikacją.

Poniższe żądanie korzysta z interfejsu Create Developer App, aby zarejestrować aplikację dla dewelopera utworzonego powyżej: ntesla@theremin.com. Podczas rejestracji aplikacji określasz jej nazwę, callbackUrl i listę co najmniej 1 usługi API:

$ curl -H "Content-type:application/json" -X POST -d \
'{
  "apiProducts": [ "weather_free"], 
  "callbackUrl" : "login.weatherapp.com", 
  "keyExpiresIn" : "2630000000",
  "name" : "weatherapp"}' \
https://api.enterprise.apigee.com/v1/o/{org_name}/developers/ntesla@theremin.com/apps \
-u email:password

Parametr callbackUrl jest używany przez niektóre typy uwierzytelnienia przez OAuth (np. kod autoryzacji) do weryfikowania żądań przekierowania z aplikacji. Jeśli używasz protokołu OAuth, ta wartość musi być taka sama jak wartość parametru redirect_uri używanego do wysyłania żądań protokołu OAuth.

Atrybut keyExpiresIn określa w milisekundach okres ważności klucza klienta, który zostanie wygenerowany dla aplikacji dewelopera. Wartość domyślna –1 oznacza nieskończony okres ważności.

Przykładowa odpowiedź

{
  "appId": "5760d130-528f-4388-8c6f-65a6b3042bd1",
  "attributes": [
    {
      "name": "DisplayName",
      "value": "Test Key Expires"
    },
    {
      "name": "Notes",
      "value": "Just testing this attribute"
    }
  ],
  "createdAt": 1421770824390,
  "createdBy": "wwitman@apigee.com",
  "credentials": [
    {
      "apiProducts": [
        {
          "apiproduct": "ProductNoResources",
          "status": "approved"
        }
      ],
      "attributes": [],
      "consumerKey": "jcAFDcfwImkJ19A5gTsZRzfBItlqohBt",
      "consumerSecret": "AX7lGGIRJs6s8J8y",
      "expiresAt": 1424400824401,
      "issuedAt": 1421770824401,
      "scopes": [],
      "status": "approved"
    }
  ],
  "developerId": "e4Oy8ddTo3p1BFhs",
  "lastModifiedAt": 1421770824390,
  "lastModifiedBy": "wwitman@apigee.com",
  "name": "TestKeyExpires",
  "scopes": [],
  "status": "approved"
}

Zarządzanie kluczami klienta w przypadku aplikacji korzystających z interfejsu API

Uzyskaj klucz klienta (klucz interfejsu API) aplikacji.

Dane logowania aplikacji (produkt interfejsu API, klucz klienta i klucz tajny) są zwracane w ramach profilu aplikacji. Administrator organizacji może w każdej chwili pobrać klucz klienta.

W profilu aplikacji wyświetlana jest wartość klucza klienta i klucza tajnego, stan klucza klienta oraz powiązania klucza z produktami interfejsu API. Jako administrator możesz w dowolnym momencie pobrać profil klucza klienta za pomocą interfejsu Get Key Details for a Developer App API:

$ curl -X GET -H "Accept: application/json" \
https://api.enterprise.apigee.com/v1/o/{org_name}/developers/ntesla@theremin.com/apps/weatherapp/keys/HQg0nCZ54adKobpqEJaE8FefGkdKFc2J \
-u email:password

Przykładowa odpowiedź

{
  "apiProducts" : [ {
    "apiproduct" : "weather_free",
    "status" : "approved"
  } ],
  "attributes" : [ ],
  "consumerKey" : "HQg0nCZ54adKobpqEJaE8FefGkdKFc2J",
  "consumerSecret" : "1eluIIdWG3JGDjE0",
  "status" : "approved"
}

Więcej informacji znajdziesz w artykule Uzyskiwanie szczegółowych informacji o kluczu aplikacji deweloperskiej.

Dodawanie produktu interfejsu API do aplikacji i klucza

Aby zaktualizować aplikację i dodać do niej nowy produkt API, musisz dodać ten produkt do klucza aplikacji za pomocą interfejsu Add API Product to Key API. Więcej informacji znajdziesz w artykule Dodawanie produktu interfejsu API do klucza.

Dodanie usługi API do klucza aplikacji umożliwia aplikacji, która ma ten klucz, dostęp do zasobów API zawartych w usłudze API. To wywołanie metody dodaje nowy produkt interfejsu API do aplikacji:

$ curl -H "Content-type:application/json" -X POST -d \
'{
  "apiProducts": [ "newAPIProduct"]
}' \
https://api.enterprise.apigee.com/v1/o/{org_name}/developers/ntesla@theremin.com/apps/weatherapp/keys/HQg0nCZ54adKobpqEJaE8FefGkdKFc2J \
-u email:password

Przykładowa odpowiedź:

{
  "apiProducts": [
   {
     "apiproduct": "weather_free",
     "status": "approved"
   },
   {
     "apiproduct": "newAPIProduct",
     "status": "approved"
   }
 ],
 "attributes": [],
 "consumerKey": "HQg0nCZ54adKobpqEJaE8FefGkdKFc2J",
 "consumerSecret": "1eluIIdWG3JGDjE0",
 "expiresAt": -1,
 "issuedAt": 1411491156464,
 "scopes": [],
 "status": "approved"
 }

Zatwierdzanie kluczy klienta

Ustawienie typu zatwierdzania na ręczne umożliwia kontrolowanie, którzy deweloperzy mogą uzyskiwać dostęp do zasobów chronionych przez usługi API. Jeśli w przypadku produktów interfejsu API zatwierdzanie klucza jest ustawione na manual, klucze konsumenckie muszą zostać wyraźnie zatwierdzone. Klucze można wyraźnie zatwierdzić za pomocą interfejsu API Approve or Revoke Specific Key of Developer App:

$ curl -X POST -H "Content-type:appilcation/octet-stream" \ 
https://api.enterprise.apigee.com/v1/o/{org_name}/developers/ntesla@theremin.com/apps/weatherapp/keys/HQg0nCZ54adKobpqEJaE8FefGkdKFc2J?"action=approve" \
-u email:password

Przykładowa odpowiedź

{
  "apiProducts" : [ {
  "apiproduct" : "weather_free",
  "status" : "approved"
} ],
  "attributes" : [ ],
  "consumerKey" : "HQg0nCZ54adKobpqEJaE8FefGkdKFc2J",
  "consumerSecret" : "1eluIIdWG3JGDjE0",
  "status" : "approved"
}

Więcej informacji znajdziesz w artykule Zatwierdzanie lub unieważnianie konkretnego klucza aplikacji dewelopera.

Zatwierdzanie usług API dla kluczy konsumenckich

Powiązanie produktu interfejsu API z kluczem klienta również ma stan. Aby dostęp do interfejsu API był możliwy, klucz klienta musi zostać zatwierdzony i musi być zatwierdzony w przypadku odpowiedniego produktu interfejsu API. Powiązanie klucza klienta z usługą API można zatwierdzić za pomocą interfejsu API Zatwierdź lub cofnij usługę API dla klucza aplikacji programisty:

$ curl -X POST -H "Content-type:application/octet-stream" \ 
https://api.enterprise.apigee.com/v1/o/{org_name}/developers/ntesla@theremin.com/apps/weatherapp/keys/HQg0nCZ54adKobpqEJaE8FefGkdKFc2J/apiproducts/weather_free?"action=approve" \
-u email:password

To polecenie cURL nie zwraca odpowiedzi. Więcej informacji znajdziesz w artykule Zatwierdzanie lub wycofywanie produktu interfejsu API dla klucza aplikacji dewelopera.

Odbieranie dostępu do usług API w przypadku kluczy konsumenckich

Istnieje wiele powodów, dla których możesz chcieć cofnąć powiązanie klucza klienta z usługą API. Konieczność usunięcia produktu interfejsu API z klucza klienta może wynikać z braku płatności ze strony dewelopera, wygaśnięcia okresu próbnego lub przejścia aplikacji z jednego produktu interfejsu API na inny.

Aby cofnąć powiązanie klucza klienta z produktem API, użyj interfejsu API Zatwierdź lub cofnij konkretny klucz aplikacji dewelopera , wykonując działanie cofnięcia w odniesieniu do klucza klienta aplikacji dewelopera:

$ curl -X POST -H "Content-type:application/octet-stream" \ 
https://api.enterprise.apigee.com/v1/o/{org_name}/developers/ntesla@theremin.com/apps/weatherapp/keys/HQg0nCZ54adKobpqEJaE8FefGkdKFc2J/apiproducts/weather_free?"action=revoke" \
-u email:password

To polecenie cURL nie zwraca odpowiedzi. Więcej informacji znajdziesz w artykule Zatwierdzanie lub unieważnianie konkretnego klucza aplikacji dewelopera.

Wymuszanie ustawień usługi API

Aby wymusić stosowanie usług API, do przepływu serwera proxy API musi być dołączony jeden z tych typów zasad:

VerifyAPIKey: przyjmuje odwołanie do klucza interfejsu API, sprawdza, czy reprezentuje on prawidłową aplikację, i czy pasuje do produktu API. Więcej informacji znajdziesz w zasadach dotyczących weryfikacji klucza interfejsu API.
OAuthV1, operacja „VerifyAccessToken”: weryfikuje podpis, sprawdza token dostępu OAuth 1.0a i „klucz klienta” oraz dopasowuje aplikację do produktu API. Obsługa OAuth 1.0a została wycofana. Więcej informacji znajdziesz w sekcji Wycofane funkcje.
OAuthV2, operacja „VerifyAccessToken”: sprawdza, czy token dostępu OAuth 2.0 jest prawidłowy, dopasowuje token do aplikacji, sprawdza, czy aplikacja jest prawidłowa, a następnie dopasowuje aplikację do produktu API. Więcej informacji znajdziesz na stronie głównej OAuth.

Po skonfigurowaniu zasad i usług API Apigee Edge wykonuje te czynności:

Żądanie jest odbierane przez Apigee Edge i kierowane do odpowiedniego proxy interfejsu API.
Wykonana zostaje zasada, która weryfikuje klucz interfejsu API lub token dostępu OAuth przedstawiony przez klienta.
Edge rozpoznaje klucz interfejsu API lub token dostępu w profilu aplikacji.
Edge rozwiązuje listę (jeśli istnieje) produktów API powiązanych z aplikacją.
Do wypełnienia zmiennych limitu wykorzystywany jest pierwszy pasujący produkt interfejsu API.
Jeśli żaden produkt API nie pasuje do klucza interfejsu API lub tokena dostępu, żądanie zostanie odrzucone.
Edge wymusza kontrolę dostępu opartą na identyfikatorze URI (środowisko, proxy interfejsu API i ścieżka URI) na podstawie ustawień usługi API oraz ustawień limitu.