Narzędzia dla programistów

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X.
Informacje

Jako dostawca usług tworzysz interfejsy API do wykorzystania przez aplikacje klienckie. Aby tworzyć, konfigurować i obsługiwać serwery proxy API oraz usługi API, możesz używać interfejsu użytkownika lub wysyłać do tych interfejsów żądania HTTP w celu uzyskania dostępu do usług REST zgodnie z opisem w poniższych sekcjach.

Korzystanie z interfejsu Edge

Interfejs Apigee Edge to narzędzie działające w przeglądarce, które pozwala tworzyć i konfigurować serwery proxy API i usługi API oraz nimi zarządzać. Część zadań można wykonywać tylko przy użyciu interfejsu API.

Tabela poniżej zawiera informacje na temat uzyskiwania dostępu do interfejsu Edge:

Produkt Nazwa interfejsu użytkownika 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 o tworzeniu pierwszego serwera proxy interfejsu API.

Edge dla chmury prywatnej Klasyczny interfejs użytkownika

Aby uzyskać dostęp do interfejsu Edge dla Edge dla 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.

W interfejsie użytkownika Edge możesz:

  • Twórz serwery proxy interfejsów API, edytując kod i śledząc przepływy żądań przez te serwery.
  • Twórz usługi API, które łączą serwery proxy pod kątem ekspozycji na żądania klientów.
  • Zarządzanie deweloperami i aplikacjami
  • Skonfiguruj środowiska testowe i produkcyjne.
  • Implementowanie aplikacji JavaScript i Node.js.

Poniższy przykład przedstawia edytor proxy interfejsu API, którego możesz użyć do utworzenia i skonfigurowania serwera proxy interfejsu API:

Pokazuje kartę Programowanie wybraną w edytorze proxy interfejsu API w interfejsie Edge.

Korzystanie z Edge API

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

Punkty końcowe interfejsu API często pobierają dane zawierające informacje o konfiguracji i wymagają podania danych uwierzytelniających, takich jak nazwa użytkownika i hasło. Zgodnie z zasadami REST możesz wywoływać metody HTTP GET, POST, PUT i DELETE w dowolnych zasobach API.

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

Omówienie ścieżki bazowej interfejsu Edge API

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

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

Jeśli na przykład nazwa organizacji to apibuilders, każde wywołanie interfejsu API będzie korzystać z tej ścieżki bazowej:

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

Aby pobrać listę serwerów proxy interfejsu API w organizacji, musisz wywołać funkcję GET:

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ęć podręczna jest ograniczona według środowiska. Udostępniona pamięć podręczna o nazwie „mycache” jest domyślnie dostępna w każdym środowisku.

Możesz wyświetlić listę pamięci podręcznych, wywołując w zasobie pamięci podręcznej funkcję GET 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

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

Dodatkowo Apigee zaleca korzystanie z uwierzytelniania dwuskładnikowego, zgodnie z opisem w sekcji Włączanie uwierzytelniania dwuskładnikowego dla konta Apigee.

Limity interfejsu Edge API

Każda organizacja podlega ograniczeniom dotyczącym następujących stawek za wywołania interfejsu Edge API:

  • 10 000 połączeń na minutę w przypadku organizacji z płatnymi abonamentami,
  • 600 połączeń na minutę w przypadku organizacji korzystających z okresu próbnego

Kody stanu HTTP 401 i 403 nie wliczają się 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 API Edge

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

Skrócenie adresów URL żądań

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

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

Jeśli używasz skrótów, musisz zachować ich spójność. To znaczy, że trzeba skrócić wszystkie elementy na ścieżce (jak wskazaliśmy powyżej i w poniższym przykładzie) lub nie używać ich wcale. Użycie w tej samej ścieżce zarówno elementów pełnych, jak i skróconych 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

wysyłać żądania do interfejsu API za pomocą klienta HTTP, W wielu przykładach w dokumentacji znajdują się przykładowe żądania do interfejsu API wykorzystujące popularnego klienta HTTP curl. Jeśli musisz zainstalować usługę curl, możesz ją pobrać ze strony http://curl.haxx.se.

Wywołania interfejsu API obsługują kompresję gzip w odpowiedziach. Jeśli ustawisz 'Accept-Encoding: gzip, deflate' w wywołaniach interfejsu API, wszystkie odpowiedzi dłuższe niż 1024 bajty będą zwracane w formacie gzip.

Formatowanie żądań i odpowiedzi w formacie XML i JSON

Interfejs Edge API domyślnie zwraca dane w formacie JSON. W przypadku wielu żądań odpowiedź możesz otrzymać z powrotem w formacie XML. W tym celu 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>

Zwróć uwagę, że w tym przykładzie użyto funkcji prettyprint do wyświetlania wyników, przesyłając odpowiedź przez potok xmllint.

Narzędzie acurl nie obsługuje nagłówka Accept. W związku z tym możesz otrzymywać odpowiedzi w formacie JSON tylko z użyciem atrybutu acurl.

Aby użyć prettyprint dla 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ładową odpowiedź:

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

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

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

Gdy wykonujesz POST lub umieszczasz ładunki w formacie XML, 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 domyślnie ma co najmniej 2 środowiska, których może używać do programowania, testowania i wdrażania interfejsów API: „testowania” i „produkcji”. Wykorzystaj środowisko „testowe”, aby tworzyć i testować swoje interfejsy API przed ich publicznym udostępnieniem. Dostęp do interfejsów API wdrożonych w środowisku testowym mają tylko Twoi wewnętrzni deweloperzy. Wdróż interfejsy API w środowisku „produkcyjnym”, 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 zawierają nagłówki oraz ładunki żądań i odpowiedzi, wykonanie zasad, wartości zmiennych i wszelkie błędy, które mogły wystąpić podczas procesu.

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

  • Sygnatury czasowe: użyj sygnatur czasowych, by sprawdzić, ile czasu zajmuje wykonanie poszczególnych kroków. Porównywanie sygnatur czasowych pomaga wyodrębnić zasady, których wykonanie trwa najdłużej, a które spowalniają wywołania interfejsu API.
  • Ścieżka bazowa: weryfikując ścieżkę bazową, możesz upewnić się, że zasada kieruje wiadomość na właściwy serwer.
  • Wyniki wykonania zasady: te wyniki pozwalają sprawdzić, czy wiadomość jest modyfikowana zgodnie z oczekiwaniami, na przykład czy wiadomość jest przekształcana z XML na JSON lub czy wiadomość jest przechowywana w pamięci podręcznej.

Ten rysunek przedstawia wyniki śledzenia:

Pokazuje kartę śledzenia wybraną w edytorze proxy interfejsu API w interfejsie Edge.

Każda sesja śledzenia jest podzielona na następujące główne kroki:

  • Pierwotne żądanie odebrane od klienta: wyświetla ścieżkę czasownika i identyfikatora URI żądania z aplikacji klienckiej, nagłówki, dane treści i parametry zapytania.
  • Żądanie wysłane do usługi backendu: wyświetla komunikat żądania wysłany do 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.
  • Ostateczna odpowiedź wysłana do klienta: po wykonaniu przepływu odpowiedzi komunikat z odpowiedzią został zwrócony do aplikacji klienckiej wysyłającej żądanie.