Narzędzia dla programistów

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

Jako dostawca usług tworzysz interfejsy API do wykorzystania przez aplikacje klienckie. Aby utworzyć, skonfigurować: a także utrzymywać serwery proxy i usługi API, możesz używać interfejsu użytkownika lub wysyłać żądania HTTP do Interfejsy API umożliwiające dostęp do usług typu REST zgodnie z opisem w kolejnych sekcjach.

Korzystanie z interfejsu Edge

Interfejs Apigee Edge to narzędzie działające w przeglądarce, za którego pomocą możesz tworzyć i konfigurować elementy oraz nimi zarządzać Serwery proxy interfejsów API i usługi API. Część zadań można wykonać tylko za pomocą interfejsu API, .

W tej tabeli opisano, jak uzyskać dostęp do interfejsu Edge:

Produkt Nazwa interfejsu URL dostępu
Edge Interfejs Edge

Aby uzyskać dostęp do interfejsu Edge, użyj tego adresu URL:

https://apigee.com/edge

Aby zapoznać się z samouczkiem dotyczącym korzystania z interfejsu Edge, zobacz Utwórz pierwszy serwer proxy interfejsu API.
Edge dla chmury prywatnej Klasyczny interfejs Edge

Aby uzyskać dostęp do interfejsu Edge dla chmury prywatnej, użyj tego adresu URL:

http://ms-ip:9000

Gdzie ms-ip to adres IP lub nazwa DNS węzła serwera zarządzania.

Za pomocą interfejsu Edge możesz:

  • Twórz serwery proxy interfejsu API, edytując kod i śledząc przepływy żądań przez serwery proxy.
  • Twórz usługi API, które łączą serwery proxy na potrzeby udostępniania żądań klientów.
  • Zarządzanie deweloperami i aplikacjami.
  • Skonfiguruj środowisko testowe i produkcyjne.
  • Wdrażanie aplikacji JavaScript i Node.js.

Poniższy obraz przedstawia edytor proxy interfejsu API, którego można użyć do utworzenia i skonfigurowania Serwer proxy interfejsu API:

Wyświetla kartę Programowanie wybraną w edytorze serwera proxy interfejsów API w interfejsie Edge.

Używanie interfejsu Edge API

Za pomocą interfejsu Edge API możesz zarządzać zasobami interfejsu API. Interfejsy API zapewniają też dostęp do funkcji niskopoziomowych, które nie są udostępniane Interfejs.

Punkty końcowe interfejsu API często przyjmują dane zawierające informacje konfiguracyjne i wymagają i przekazywać dane uwierzytelniające, takie jak nazwa użytkownika i hasło, w celu uzyskania do nich dostępu. Obserwujesz RESTful zasad, możesz wywoływać HTTP GET, POST, PUT oraz DELETE w dowolnym zasobie interfejsu API.

Pełną listę interfejsów Apigee Edge API znajdziesz w Dokumentacja interfejsu API Apigee

Informacje o podstawach interfejsu Edge API ścieżka

Ścieżka, której będziesz używać w żądaniach do interfejsu API, składa się z tych elementów:

  • Ścieżka podstawowa zawierająca nazwę organizacji. Na przykład: https://api.enterprise.apigee.com/v1/organizations/org_name
  • Punkt końcowy wskazujący zasób Edge, do którego próbujesz uzyskać dostęp.

Jeśli na przykład nazwa Twojej organizacji to apibuilders, wtedy każde połączenie nawiązane przez Interfejs API będzie używać tej ścieżki podstawowej:

https://api.enterprise.apigee.com/v1/organizations/apibuilders

Aby pobrać listę serwerów proxy interfejsu API w organizacji, wywołaj metodę GET w:

https://api.enterprise.apigee.com/v1/organizations/apibuilders/apis

Wiele zasobów ma zakres ograniczony do konkretnego środowiska. Domyślnie udostępniane są 2 środowiska: testowe i produkcja Na przykład pamięci podręczne są ograniczone do środowiska. Udostępniona pamięć podręczna o nazwie „mycache” jest uwzględniony domyślnie w każdym środowisku.

Możesz wyświetlić listę pamięci podręcznych, wywołując metodę GET w zasobie pamięci podręcznej w następujący sposób:

https://api.enterprise.apigee.com/v1/organizations/apibuilders/environments/test/caches
https://api.enterprise.apigee.com/v1/organizations/apibuilders/environments/prod/caches

Uwierzytelnij dostęp

Gdy wywołujesz interfejsy API, musisz uwierzytelnić się na serwerze API. Możesz zrobić możesz to zrobić na jeden z tych sposobów:

Oprócz tego Apigee zaleca korzystanie z uwierzytelniania dwuskładnikowego, jak opisano w Włącz uwierzytelnianie dwuskładnikowe na koncie Apigee.

Limity interfejsu Edge API

W każdej organizacji obowiązują następujące stawki za wywołania interfejsu Edge API:

  • 10 tys. połączeń na minutę dla organizacji korzystających z płatnych abonamentów
  • 600 połączeń na minutę dla organizacji korzystających z okresu próbnego;

Kody stanu HTTP 401 i 403 nie wliczają się do tego limitu. Wszystkie połączenia przekraczające te limity zwraca kod stanu 429 Too Many Requests.

Wskazówki dotyczące pracy z interfejsami API Edge

W tej sekcji opisano niektóre techniki pozwalające na pracę z interfejsami Edge API. .

Skrócenie adresów URL żądań

Podczas tworzenia adresu URL żądania do interfejsów Edge API możesz użyć tego skróty:

  • /e = /environments
  • /o = /organizations
  • /r = /revisions

Stosując skróty, musisz stosować je konsekwentnie. Oznacza to, że należy skrócić wszystkie elementy w jak zaznaczono powyżej i na poniższym przykładzie, albo „brak”. Użycie w tej samej ścieżce zarówno pełnych, jak i skróconych elementów spowoduje błąd.

Na przykład:

THIS:
https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/environments/prod/apis/helloworld/revisions/1/deployments
CAN BE MUCH SHORTER:
https://api.enterprise.apigee.com/v1/o/ahamilton-eval/e/prod/apis/helloworld/r/1/deployments

Wykonywanie poleceń curl

Używanie klienta HTTP do wysyłania żądań do interfejsu API. Wiele przykładów w dokumentacji udostępnienie przykładowych żądań do interfejsu API za pomocą popularnego klienta HTTP curl, W razie potrzeby Zainstaluj aplikację curl, możesz ją pobrać z http://curl.haxx.se.

Wywołania interfejsu API obsługują kompresję gzip odpowiedzi. Jeśli ustawisz 'Accept-Encoding: gzip, deflate' w wywołaniach interfejsu API, odpowiedź większa niż 1024 bajty jest zwracana w formacie gzip.

Formatowanie żądań i odpowiedzi XML i JSON

Edge API domyślnie zwraca dane w formacie JSON. W przypadku wielu próśb możesz otrzymać odpowiedź odesłana jako plik XML. Aby to zrobić, ustaw nagłówek żądania Accept na application/xml, jak widać w tym przykładzie:

curl -H "Authorization: Bearer `get_token`" \
  -H "Accept: application/xml" \
  https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/apis/helloworld/revisions/1/policies/ \
  | xmllint --format -

Odpowiedź powinna wyglądać tak:

<List>
  <Item>SOAP-Message-Validation-1</Item>
  <Item>Spike-Arrest-1</Item>
  <Item>XML-to-JSON-1</Item>
</List>

Zwróć uwagę, że w tym przykładzie użyto parametru prettyprint do wyświetlania wyników przez zatłoczenie odpowiedzi xmllint

Narzędzie acurl nie obsługuje nagłówka Accept. Umożliwia to otrzymują tylko odpowiedzi w formacie JSON z funkcją acurl.

Aby użyć metody prettyprint w odpowiedzi JSON, możesz użyć biblioteki Pythona json.tool:

curl https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/apis/helloworld/revisions/1/policies/ \
  -H "Accept: application/json" \
  -H "Authorization: Bearer `get_token`" \
  | python -m json.tool

Oto przykład takiej odpowiedzi:

[
  "SOAP-Message-Validation-1",
  "Spike-Arrest-1",
  "XML-to-JSON-1"
]

W przypadku kodu XML możesz użyć zapisu xmllint:

curl https://ahamilton-eval-test.apigee.net/getstarted -u email_address | xmllint --format -

Przy wysyłaniu ładunków w formacie XML używaj nagłówka HTTP Content-type:

acurl -H "Content-type:text/xml" -X POST -d \
'<XMLPayload>
 </XMLPayload> ' \
https://api.enterprise.apigee.com/v1/organizations/apifactory/apis -u email_address

Środowiska wdrożenia

Każda organizacja korzystająca domyślnie z Apigee Edge ma co najmniej 2 środowiska, które może wykorzystać do Programowanie, testowanie i wdrażanie interfejsów API: „test” i „prod”. Użycie przycisku „test” do programowania i testowania interfejsów API przed ich publicznym udostępnieniem. Dostęp do interfejsów API mają tylko programiści wewnętrzni i wdrożono w środowisku testowym. Wdrażanie interfejsów API w środowisku „prod” w środowisku publicznym, dla deweloperów aplikacji.

Debugowanie i testowanie

Apigee udostępnia narzędzie śledzenia, które umożliwia debugowanie kompleksowe żądania i odpowiedzi procesu. Wyniki śledzenia zawierają nagłówki i ładunki żądań i odpowiedzi, wykonanie zasad zmiennych i błędów, które wystąpiły w trakcie przepływu danych.

Najważniejsze dane potrzebne podczas rozwiązywania problemów:

  • Sygnatury czasowe: dzięki sygnaturom czasowym możesz sprawdzać, ile czasu zajmuje wykonanie poszczególnych kroków. Porównywanie sygnatur czasowych pomaga wyodrębnić zasady, których wykonanie trwa najdłużej spowalniają wywołania interfejsu API.
  • Ścieżka podstawowa: dzięki weryfikacji ścieżki podstawowej możesz mieć pewność, że zasada i kierowanie wiadomości na właściwy serwer.
  • Wyniki wykonania zasady: te wyniki pozwalają sprawdzić, czy wiadomość jest zmieniana zgodnie z oczekiwaniami, na przykład jeśli komunikat jest przekształcany z XML na JSON lub jeśli wiadomości są zapisywane w pamięci podręcznej.

Ten rysunek przedstawia wyniki logu czasu:

Wyświetla kartę Trace wybraną w edytorze serwera proxy interfejsu API w interfejsie Edge.

Każda sesja Trace jest podzielona na te główne kroki:

  • Pierwotne żądanie otrzymane od klienta: wyświetla ścieżkę czasownika i identyfikatora URI żądania z aplikacji klienckiej, nagłówki, dane i parametry zapytania.
  • Żądanie wysłane do usługi backendu: wyświetla wiadomość żądania wysłaną do z usługi backendu przez serwer proxy interfejsu API.
  • Odpowiedź zwrócona przez usługę backendu: wyświetla nagłówki odpowiedzi. i ładunek zwrócony przez usługę backendu.
  • Ostatnia odpowiedź wysłana do klienta: wiadomość z odpowiedzią zwrócona do klienta żądania aplikacji klienckiej po wykonaniu przepływu odpowiedzi.