Narzędzia dla programistów

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

Jako dostawca usług tworzysz interfejsy API, z których korzystają aplikacje klienckie. Aby tworzyć, konfigurować, i utrzymywać serwery proxy interfejsu API oraz usługi interfejsu API, możesz używać interfejsu lub wysyłać żądania HTTP do interfejsów API, aby uzyskiwać dostęp do usług RESTful, zgodnie z opisem w kolejnych sekcjach.

Korzystanie z interfejsu Edge

Interfejs Apigee Edge to narzędzie przeglądarkowe, którego możesz używać do tworzenia, konfigurowania i zarządzania serwerami proxy interfejsu API oraz usługami interfejsu API. Podzbiór zadań można wykonać tylko za pomocą interfejsu API, też.

W tabeli poniżej opisujemy, jak uzyskać dostęp do interfejsu Edge:

Produkt Nazwa interfejsu Adres URL dostępu
Edge Interfejs Edge

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

https://apigee.com/edge

Samouczek dotyczący korzystania z interfejsu Edge znajdziesz w artykule Tworzenie pierwszego serwera proxy interfejsu API.
Edge for Private Cloud Klasyczny interfejs Edge

Aby uzyskać dostęp do interfejsu Edge w Edge for Private Cloud, 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:

  • tworzyć serwery proxy interfejsu API, edytując kod i śledząc przepływy żądań przez serwery proxy;
  • tworzyć usługi interfejsu API, które łączą serwery proxy w celu udostępniania ich żądaniom klientów;
  • zarządzać deweloperami i aplikacjami deweloperów;
  • konfigurować środowiska testowe i produkcyjne;
  • wdrażać aplikacje JavaScript i Node.js.

Na ilustracji poniżej widać edytor serwera proxy interfejsu API w interfejsie, którego możesz używać do tworzenia i konfigurowania serwera proxy interfejsu API:

Pokazuje kartę Develop (Tworzenie) wybraną w edytorze proxy interfejsu API w interfejsie Edge.

Korzystanie z interfejsu Edge API

Do zarządzania zasobami interfejsu API możesz używać interfejsu Edge API. Interfejsy API zapewniają też dostęp do funkcji niskiego poziomu, które nie są udostępniane przez interfejs.

Punkty końcowe interfejsu API często przyjmują dane zawierające informacje o konfiguracji i wymagają przekazania informacji uwierzytelniających, takich jak nazwa użytkownika i hasło, aby uzyskać do nich dostęp. Zgodnie z zasadami RESTful możesz wywoływać metody HTTP GET, POST, PUT i DELETE w przypadku dowolnego zasobu interfejsu API.

Pełną listę interfejsów Apigee Edge API znajdziesz w dokumentacji Apigee Edge API.

Informacje o ścieżce podstawowej interfejsu Edge API

Ścieżka, której będziesz używać w żądaniach interfejsu API, łączy te elementy:

  • Ścieżka podstawowa , która zawiera nazwę Twojej organizacji. Przykład: https://api.enterprise.apigee.com/v1/organizations/org_name
  • Punkt końcowy , który wskazuje zasób Edge, do którego uzyskujesz dostęp.

Jeśli na przykład nazwa Twojej organizacji to apibuilders, każde wywołanie interfejsu 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 jest ograniczonych do środowiska. Domyślnie dostępne są 2 środowiska: testowe i produkcyjne. Na przykład pamięci podręczne są ograniczone do środowiska. Domyślnie w każdym środowisku znajduje się współdzielona pamięć podręczna o nazwie „mycache” .

Aby wyświetlić listę pamięci podręcznych, wywołaj metodę GET w zasobie pamięci podręcznej w ten sposób:

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

Uwierzytelnianie dostępu

Podczas wywoływania interfejsów API musisz uwierzytelnić się na serwerze interfejsu API. Możesz to zrobić na jeden z tych sposobów:

Apigee zaleca też używanie uwierzytelniania dwuskładnikowego zgodnie z opisem w artykule Włączanie uwierzytelniania dwuskładnikowego na koncie Apigee.

Limity interfejsu Edge API

Każda organizacja jest ograniczona do tych limitów wywołań interfejsu Edge API:

  • 10 tys. wywołań na minutę w przypadku organizacji korzystających z płatnych planów.
  • 600 wywołań na minutę w przypadku organizacji korzystających z wersji próbnej.

Kody stanu HTTP 401 i 403 nie są wliczane do tego limitu. Wszystkie wywołania, które przekraczają te limity, zwracają kod stanu 429 Too Many Requests.

Wskazówki dotyczące pracy z interfejsami Edge API

W tej sekcji opisujemy kilka technik, które ułatwiają pracę z interfejsami Edge API łatwiejsze.

Skracanie adresów URL żądań

Podczas tworzenia adresu URL żądania do interfejsów Edge API możesz używać tych skrótów:

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

Jeśli używasz skrótów, musisz robić to konsekwentnie. Oznacza to, że musisz skrócić wszystkie elementy ścieżki (jak opisano powyżej i pokazano w przykładzie poniżej) lub żadne. 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

Do wysyłania żądań do interfejsu API używaj klienta HTTP. Wiele przykładów w dokumentacji zawiera przykładowe żądania interfejsu API z użyciem curl, powszechnie używanego klienta HTTP. Jeśli musisz zainstalować curl, możesz pobrać go ze strony http://curl.haxx.se.

Wywołania interfejsu API obsługują kompresję gzip odpowiedzi. Jeśli w wywołaniach interfejsu API ustawisz 'Accept-Encoding: gzip, deflate', każda odpowiedź o rozmiarze większym niż 1024 bajty zostanie zwrócona w formacie gzip.

Formatowanie żądań i odpowiedzi XML oraz JSON

Interfejs Edge API domyślnie zwraca dane w formacie JSON. W przypadku wielu żądań możesz zamiast tego otrzymać odpowiedź w formacie XML. Aby to zrobić, ustaw nagłówek żądania Accept na application/xml, jak pokazano 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>

Pamiętaj, że w tym przykładzie używamy prettyprint do wyświetlania wyników przez przekierowanie odpowiedzi przez xmllint.

Narzędzie acurl nie obsługuje nagłówka Accept. Dlatego możesz otrzymywać tylko odpowiedzi w formacie JSON za pomocą acurl.

Aby użyć prettyprint w przypadku 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

Poniżej znajdziesz przykład odpowiedzi:

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

W przypadku formatu XML możesz użyć xmllint:

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

Podczas wysyłania ładunków w formacie XML za pomocą metod POST lub PUT użyj 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 z Apigee Edge ma domyślnie co najmniej 2 środowiska, których może używać do tworzenia, testowania i wdrażania interfejsów API: „test” i „prod”. Używaj środowiska "test" do tworzenia i testowania interfejsów API, zanim udostępnisz je publicznie. Tylko wewnętrzni deweloperzy mogą uzyskiwać dostęp do interfejsów API wdrożonych w środowisku testowym. Wdróż interfejsy API w środowisku "prod", aby udostępnić je publicznie deweloperom aplikacji.

Debugowanie i testowanie

Apigee udostępnia narzędzie do śledzenia, które umożliwia debugowanie kompleksowych przepływów żądań i odpowiedzi. Wyniki śledzenia wyświetlają nagłówki i ładunki żądań oraz odpowiedzi, wykonanie zasad, wartości zmiennych i wszelkie błędy, które mogły wystąpić podczas przepływu.

Kluczowe punkty danych do wykorzystania podczas rozwiązywania problemów:

  • Sygnatury czasowe: używaj sygnatur czasowych, aby sprawdzić, ile czasu zajmuje wykonanie każdego kroku. Porównywanie sygnatur czasowych pomaga wyodrębnić zasady, których wykonanie trwa najdłużej i które spowalniają wywołania interfejsu API.
  • Ścieżka podstawowa: sprawdzając ścieżkę podstawową, możesz się upewnić, że zasada kieruje wiadomość do prawidłowego serwera.
  • Wyniki wykonania zasad: te wyniki pozwalają sprawdzić, czy wiadomość jest zmieniana zgodnie z oczekiwaniami, np. czy jest przekształcana z formatu XML na JSON lub czy jest zapisywana w pamięci podręcznej.

Na ilustracji poniżej widać wyniki śledzenia:

Wyświetla kartę Śledzenie wybraną w edytorze proxy interfejsu API w interfejsie Edge.

Każda sesja śledzenia jest podzielona na te główne etapy:

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