Wyświetlasz dokumentację Apigee Edge.
Przejdź do
dokumentacji Apigee X. info
Organizacja to kontener najwyższego poziomu w Apigee Edge. Zawiera wszystkie proxy interfejsu API i powiązane zasoby. W dalszej części tego artykułu znajdziesz więcej informacji o organizacjach, oto kilka praktycznych wskazówek:
- Domyślnie nazwa Twojej organizacji znajduje się w adresie URL używanym do wywoływania proxy interfejsu API, jak
opisano w Informacje o hostach wirtualnych.
Na przykład:
http(s)://your_org_name-environment.apigee.net/proxy_base_path/...
- Nazwa Twojej organizacji znajduje się w adresie URL interfejsu zarządzania Edge. Na przykład ten adres URL wyświetla proxy interfejsu API dla organizacji
docs:
- Mimo że możesz mieć tylko 1 organizację, możesz należeć do innych organizacji jako użytkownik lub administrator z określonymi uprawnieniami. Jeśli w interfejsie zarządzania Edge należysz do więcej niż 1 organizacji, możesz przełączyć się na inną organizację, jak opisano w sekcji Przełączanie się między organizacjami.
- Gdy jako użytkownik z rolą administratora organizacji wykonujesz wywołania za pomocą interfejsu Management API, organizacja jest wymaganą częścią ścieżki w większości wywołań. Na przykład to
żądanie cURL interfejsu Management API zwraca listę wszystkich proxy interfejsu API w organizacji:
curl https://api.enterprise.apigee.com/v1/organizations/your_org_name/apis -u org_admin_email_address
Film: obejrzyj krótki film, aby dowiedzieć się, jak organizacje obsługują architekturę wielodostępności na potrzeby zarządzania interfejsami API.
Komponenty organizacji
Gdy utworzysz konto Edge, Edge automatycznie utworzy dla Ciebie organizację. Po utworzeniu organizacji możesz dodawać do niej użytkowników, tworzyć proxy interfejsu API i usługi API oraz rejestrować deweloperów i aplikacje.
Obraz poniżej przedstawia główne komponenty modelu organizacji Edge. Ten model określa, jak interfejsy API, usługi API, aplikacje i deweloperzy aplikacji są powiązani w Edge.

Ten model nie pokazuje wszystkich funkcji Apigee Edge. Jeśli korzystasz z zarabiania, model będzie miał dodatkowe komponenty. Więcej informacji znajdziesz w artykule Omówienie zarabiania. Informacje o zarządzaniu firmami i deweloperami za pomocą zarabiania znajdziesz w artykule Zarządzanie firmami i deweloperami.
Nazwy organizacji
Nazwa organizacji to:
- Organizacja testowa:
username-eval - Organizacja płatna: zdefiniowana przez użytkownika podczas wstępnej konfiguracji
Po utworzeniu organizacji nie można zmienić jej nazwy.
Nazwa organizacji staje się częścią adresu URL proxy interfejsu API i częścią adresu URL podczas wysyłania żądania do interfejsu Edge Management API. Na przykład typowy adres URL używany do uzyskiwania dostępu do proxy interfejsu API ma postać:
http://org-name-env.apigee.net/v1/weather/forecastrss
gdzie:
- org-name to nazwa Twojej organizacji.
- env to środowisko wdrożenia proxy interfejsu API, które może być testowe lub produkcyjne.
Na przykład:
http://myorg-test.apigee.net/v1/weather/forecastrss
Komponenty organizacji
Tabela poniżej zawiera szczegółowe informacje o komponentach modelu organizacji:
| Komponent | Opis |
|---|---|
|
Organizacja |
Każde konto Apigee jest powiązane z co najmniej 1 organizacją w Apigee Edge. Organizacja zawiera reprezentację wszystkich komponentów, w tym proxy interfejsu API, usług API, pakietów API, aplikacji i deweloperów. Właściciele kont nie są ograniczeni do 1 organizacji. Niektórzy właściciele kont mogą definiować wiele organizacji lub być ich członkami, aby obsługiwać różne społeczności deweloperów aplikacji. |
| Środowisko | Kontekst wykonania środowiska wykonawczego dla proxy interfejsu API w organizacji. Więcej informacji o środowiskach znajdziesz w sekcji poniżej. |
|
Użytkownik |
W organizacji, w której osoba tworząca konto jest automatycznie administratorem, możesz utworzyć więcej użytkowników. Użytkownicy tworzą zespół ds. interfejsu API organizacji, który może obejmować m.in. administratorów, twórców proxy interfejsu API i usług API, użytkowników monitorujących statystyki i inne dane oraz inne osoby. Różni użytkownicy mogą mieć różne role i uprawnienia dostępu. Możesz na przykład zdefiniować niektórych użytkowników jako administratorów organizacji i administratorów operacji z uprawnieniami do modyfikowania organizacji i jej komponentów. Możesz też zdefiniować innych użytkowników z uprawnieniami do tworzenia proxy interfejsu API i usług API, ale bez uprawnień do modyfikowania innych użytkowników. Użytkownicy mogą być członkami wielu organizacji. Na przykład Twoja firma może zdefiniować wiele organizacji w Apigee Edge, aby obsługiwać różne społeczności deweloperów. Wewnętrznie jednak te same osoby tworzą wszystkie proxy interfejsu API i usługi API, dlatego są członkami wszystkich Twoich organizacji. Aby być użytkownikiem, nie musisz tworzyć konta Apigee, czyli organizacji Apigee. Administrator może dodać Cię do istniejącej organizacji. Wszyscy użytkownicy logują się w Apigee Edge tutaj: https://enterprise.apigee.com. |
|
Proxy interfejsu API |
Użytkownicy w organizacji tworzą co najmniej 1 proxy interfejsu API. Proxy interfejsu API definiuje mapowanie publicznie dostępnego punktu końcowego HTTP na usługę backendową. Proxy interfejsu API można też skonfigurować tak, aby obejmowało zabezpieczenia (np. OAuth), przekształcało wiadomości (np. XML na JSON), ograniczało ruch do usług backendowych i wykonywało inne przydatne operacje na żądaniu, odpowiedzi i wywołaniach usług. Edge zbiera dane na potrzeby analizy proxy interfejsu API. |
|
Usługa API |
Użytkownicy w organizacji tworzą co najmniej 1 usługę API, która jest a bundle of API proxies combined with a service plan. Ten plan usług może ustawiać limity dostępu do proxy interfejsu API, zapewniać bezpieczeństwo, umożliwiać monitorowanie i analizę oraz udostępniać dodatkowe funkcje. Edge zbiera dane na potrzeby analizy usług API. |
|
Deweloper |
Organizacja zawiera co najmniej 1 dewelopera, który tworzy aplikacje korzystające z interfejsów API (zgrupowanych w usługi API) zdefiniowanych przez Twoją organizację. Deweloperzy korzystają z interfejsów API ale nie mogą ich tworzyć ani wykonywać żadnych innych działań w organizacji. Deweloperzy mogą być pracownikami Twojej firmy, partnerami lub deweloperami zewnętrznymi, którzy płacą za dostęp do Twoich interfejsów API. Aby deweloperzy mogli zarejestrować aplikację i otrzymać klucz interfejsu API umożliwiający dostęp do Twoich interfejsów API, muszą być zarejestrowani w Twojej organizacji. Jako dostawca interfejsu API musisz określić jak dodawać, aktualizować i usuwać deweloperów w swojej organizacji. Możesz dodawać ich ręcznie przez interfejs zarządzania Edge, utworzyć portal dla programistów, aby rejestrować ich za pomocą strony internetowej, lub zdefiniować własny mechanizm rejestracji za pomocą interfejsu Edge Management API. Deweloper nie musi mieć konta w Edge, a większość deweloperów nie będzie musiała niczego wiedzieć o Edge. Jeśli deweloper ma konto w Edge, zwykle jest to konto użytkownika w innej organizacji lub konto umożliwiające korzystanie z usług Edge API. |
|
Aplikacja |
Deweloperzy tworzą co najmniej 1 aplikację kliencką, która korzysta z Twoich interfejsów API. Deweloperzy muszą zarejestrować swoje aplikacje w Twojej organizacji. Aplikacja w Edge to reprezentacja rzeczywistej aplikacji dewelopera, która udostępnia deweloperowi klucz interfejsu API do przekazywania w każdym żądaniu do Twoich interfejsów API. Ponieważ wszystkie aplikacje są zarejestrowane w Twojej organizacji, możesz używać Edge do monitorowania i zbierania informacji analitycznych o aplikacji i jej użyciu Twoich interfejsów API. |
|
Klucz interfejsu API/token OAuth |
W zależności od mechanizmu autoryzacji zdefiniowanego dla Twoich interfejsów API aplikacja przekazuje klucz interfejsu API wraz z każdym żądaniem do Twoich interfejsów API. Jeśli klucz jest prawidłowy, żądanie jest dozwolone. Edge obsługuje różne typy uwierzytelniania, takie jak prosty klucz interfejsu API, dwuskładnikowe uwierzytelnianie OAuth, trzyskładnikowe uwierzytelnianie OAuth i inne. Jako dostawca interfejsu API musisz określić sposób rejestrowania aplikacji przez deweloperów. Po zarejestrowaniu aplikacji zwracasz deweloperowi klucz wymagany do uzyskania dostępu do Twoich interfejsów API. Podczas rejestracji aplikacji deweloper może wybrać dostęp do 1 lub kilku usług API usług API. Rzeczywista aplikacja dewelopera używa tego samego klucza do uzyskiwania dostępu do wszystkich usług API powiązanych z aplikacją (zarejestrowaną reprezentacją aplikacji dewelopera w Edge). W każdej chwili możesz cofnąć klucz, aby aplikacja dewelopera nie miała już dostępu do Twoich interfejsów API (nawet jeśli zarejestrowana reprezentacja aplikacji dewelopera nadal istnieje w Twojej organizacji). Możesz też określić limit czasu dla klucza, aby deweloper musiał odświeżyć klucz po określonym czasie. |
Informacje o środowiskach
Środowisko to kontekst wykonania środowiska wykonawczego dla proxy interfejsu API w organizacji. Aby można było uzyskać dostęp do proxy interfejsu API, musisz je wdrożyć w środowisku. Proxy interfejsu API możesz wdrożyć w 1 lub kilku środowiskach.
Organizacja może zawierać wiele środowisk. Możesz na przykład zdefiniować w organizacji środowiska dev,
test, i prod.
Organizacja zapewnia zakres niektórych funkcji Apigee. Na przykład dane mapy klucz-wartość (KVM) mogą być dostępne na poziomie organizacji, co oznacza, że proxy interfejsu API wdrożone w dowolnym środowisku będą otrzymywać te same dane z KVM. Niektóre funkcje, takie jak buforowanie, mogą być ograniczone do organizacji lub do określonego środowiska w organizacji. Dane analityczne Apigee są dzielone według kombinacji organizacji i środowiska.
Poniżej przedstawiamy główne elementy, którymi zarządzasz w organizacji, w tym te zdefiniowane globalnie w organizacji i te zdefiniowane konkretnie dla środowiska:
