Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje
Organizacja to kontener najwyższego poziomu w Apigee Edge. Zawiera wszystkie serwery proxy interfejsu API i powiązane zasoby. W dalszej części tego artykułu bardziej szczegółowo opisujemy organizacje, oto kilka praktycznych wskazówek:
- Domyślnie nazwa organizacji znajduje się w adresie URL służącym do wywoływania serwerów proxy interfejsu API, zgodnie z opisem w sekcji Informacje o hostach wirtualnych.
Przykład:
http(s)://your_org_name-environment.apigee.net/proxy_base_path/...
- Nazwa organizacji znajduje się w adresie URL interfejsu zarządzania Edge. Na przykład ten adres URL wyświetla serwery proxy interfejsów API w organizacji
docs:
- Mimo że masz utworzoną tylko jedną organizację, możesz należeć do innych organizacji jako użytkownik lub administrator z określonymi uprawnieniami. Jeśli należysz do więcej niż 1 organizacji, w interfejsie zarządzania brzegowymi możesz przełączyć się na inną organizację zgodnie z opisem w sekcji Przełączanie się między organizacjami.
- Gdy wykonujesz wywołania za pomocą interfejsu Management API jako użytkownik o roli administratora organizacji, organizacja jest wymaganym elementem ścieżki w większości wywołań. Na przykład to żądanie cURL interfejsu Management API zwraca listę wszystkich serwerów 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ę środowiska wielu najemców w zakresie zarządzania interfejsami API.
Komponenty organizacji
Gdy tworzysz konto Edge, Edge automatycznie tworzy dla Ciebie organizację. Po utworzeniu możesz dodawać użytkowników do organizacji, tworzyć serwery proxy interfejsów API i usługi API oraz rejestrować deweloperów i aplikacje.
Poniższa ilustracja przedstawia główne komponenty modelu organizacyjnego Edge. Ten model definiuje sposób powiązania interfejsów API, usług API, aplikacji i deweloperów aplikacji w Edge.
Ten model nie pokazuje wszystkich funkcji Apigee Edge. Jeśli skorzystasz z funkcji zarabiania, model będzie miał dodatkowe komponenty. Więcej informacji znajdziesz w artykule Omówienie zarabiania. Informacje o zarządzaniu firmami i deweloperami z możliwością zarabiania znajdziesz w artykule Zarządzanie firmami i deweloperami.
Nazwy organizacji
Nazwa organizacji:
- Organizacja oceny:
username-eval - Organizacja płatna:zdefiniowana przez użytkownika w momencie początkowej obsługi administracyjnej
Po utworzeniu organizacji nie możesz zmienić jej nazwy.
Podczas wysyłania żądania do interfejsu Edge Management API nazwa organizacji staje się częścią adresu URL serwerów proxy interfejsu API i adresu URL. Na przykład typowy URL używany do uzyskiwania dostępu do serwera 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 serwera 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 na temat komponentów modelu organizacyjnego:
| Komponent | Opis |
|---|---|
|
Organizacja |
Każde konto Apigee jest mapowane na co najmniej 1 organizację w Apigee Edge. Organizacja zawiera wszystkie komponenty, w tym serwery proxy interfejsów API, usługi API, pakiety API, aplikacje i programistów. Właściciele kont nie muszą ograniczać się do jednej organizacji. Niektórzy właściciele kont mogą definiować wiele organizacji wspierających różne społeczności deweloperów aplikacji lub należeć do tych, które należą do kilku. |
| Środowisko | Kontekst wykonywania w środowisku wykonawczym serwerów proxy interfejsów API w organizacji. W sekcji poniżej znajdziesz więcej informacji o środowiskach. |
|
Użytkownik |
W organizacji, w której osoba tworząca konto jest automatycznie administratorem, możesz tworzyć kolejne konta użytkowników. Użytkownicy tworzą w organizacji zespół ds. interfejsów API, w którego skład wchodzą między innymi administratorzy, twórcy usług proxy interfejsów API i interfejsów API, użytkownicy monitorujący statystyki i inne statystyki. Różni użytkownicy mogą mieć różne role i uprawnienia dostępu. Zdefiniuj niektórych użytkowników jako administratorów organizacji i administratorów operacyjnych z uprawnieniami do modyfikowania organizacji i jej składników. Zdefiniuj innych użytkowników z uprawnieniami do tworzenia serwerów proxy interfejsów API i usług API, ale bez uprawnień do modyfikowania innych użytkowników. Użytkownicy mogą należeć do wielu organizacji. Na przykład Twoja firma może zdefiniować wiele organizacji w Apigee Edge, aby wspierać różne społeczności programistów. Wewnętrznie jednak te same osoby tworzą wszystkie serwery proxy i usługi API interfejsów API, więc należą do wszystkich Twoich organizacji. Aby zostać użytkownikiem, nie musisz tworzyć konta Apigee – czyli utworzyć organizację 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 serwer proxy interfejsu API. Serwer proxy interfejsu API definiuje mapowanie publicznie dostępnego punktu końcowego HTTP na usługę backendu. Serwery proxy interfejsów API można też skonfigurować tak, aby uwzględniały zabezpieczenia (na przykład OAuth), przeprowadzały przekształcanie wiadomości (np. z XML na JSON), ograniczały ruch do usług backendu oraz wykonują inne cenne operacje dotyczące żądań, odpowiedzi i wywołań usług. Edge zbiera dane do analiz na serwerach proxy interfejsów API. |
|
Usługa API |
Użytkownicy w organizacji tworzą co najmniej 1 usługę API, przy czym usługa API to pakiet serwerów proxy API połączonych z abonamentem. Ten abonament może określać limity dostępu do serwerów proxy interfejsów API, zapewniać bezpieczeństwo, umożliwiać monitorowanie i analizy oraz udostępniać dodatkowe funkcje. Edge zbiera dane na potrzeby analiz usług API. |
|
Deweloper |
W organizacji jest co najmniej 1 deweloper, który tworzy aplikacje korzystające z interfejsów API (połączonych w usługi interfejsów API) zdefiniowanych przez organizację. Programiści korzystają z interfejsów API, ale nie mogą tworzyć interfejsów API ani wykonywać innych czynności w organizacji. Mogą oni być wewnętrznie w Twojej firmie, mogą być partnerami lub zewnętrznymi deweloperami, którzy płacą za dostęp do Twoich interfejsów API. Aby móc zarejestrować aplikację i otrzymać klucz interfejsu API zapewniający dostęp do Twoich interfejsów API, deweloperzy muszą być zarejestrowani w Twojej organizacji. Jako dostawca interfejsu API to Ty decydujesz, jak dodawać, aktualizować i usuwać programistów w organizacji. Możesz dodać je ręcznie w interfejsie zarządzania brzegiem, utworzyć portal dla programistów, aby zarejestrować je na stronie, lub zdefiniować własny mechanizm rejestracji przy użyciu interfejsu Edge Management API. Deweloper nie musi mieć konta w Edge, a większość deweloperów nie będzie musiała wiedzieć nic o Edge. Jeśli deweloper ma konto w Edge, zwykle jest to użytkownik w innej organizacji lub korzysta z usług Edge API. |
|
Promująca aplikację |
Deweloperzy tworzą co najmniej jedną aplikację kliencką, która korzysta z Twoich interfejsów API. Deweloperzy muszą zarejestrować swoje aplikacje w Twojej organizacji. Aplikacja w Edge reprezentuje faktyczną aplikację dewelopera. Zapewnia mu klucz interfejsu API, który musi przekazywać w każdym żądaniu do Twoich interfejsów API. Wszystkie aplikacje są zarejestrowane w Twojej organizacji, więc możesz za pomocą Edge monitorować i zbierać dane analityczne dotyczące aplikacji i używania przez nią interfejsów API. |
|
Klucz interfejsu API/token OAuth |
W zależności od mechanizmu autoryzacji zdefiniowanego dla interfejsów API aplikacja przekazuje klucz API wraz z każdym żądaniem do tych interfejsów. Jeśli ten klucz jest prawidłowy, żądanie jest dozwolone. Edge obsługuje różne typy uwierzytelniania, takie jak prosty klucz interfejsu API, dwuetapowa autoryzacja OAuth, trzyetapowa autoryzacja OAuth. Jako dostawca interfejsu API musisz określić sposób, w jaki deweloperzy mogą rejestrować swoje aplikacje. Gdy zarejestrujesz aplikację, zwrócisz deweloperowi klucz wymagany do uzyskania dostępu do interfejsów API. W momencie rejestracji aplikacji deweloper może wybrać dostęp do jednej lub wielu usług API. Rzeczywista aplikacja dewelopera używa tego samego klucza, aby uzyskać dostęp do wszystkich usług API powiązanych z aplikacją (zarejestrowana reprezentacja aplikacji dewelopera w Edge). W każdej chwili możesz unieważnić ten klucz, aby aplikacja dewelopera nie miała już dostępu do Twoich interfejsów API (nawet jeśli zarejestrowana reprezentacja aplikacji dewelopera nadal będzie istnieć w Twojej organizacji). Możesz też określić limit czasu działania klucza, tak aby deweloper musiał odświeżać go po określonym czasie. |
Informacje o środowiskach
Środowisko to kontekst wykonywania w czasie działania serwerów proxy interfejsów API w organizacji. Aby uzyskać dostęp do środowiska, musisz wdrożyć w środowisku serwer proxy interfejsu API. Serwer proxy interfejsu API możesz wdrożyć w jednym lub w wielu środowiskach.
Organizacja może zawierać wiele środowisk. Możesz na przykład zdefiniować środowisko dev, test i prod w organizacji.
Organizacja określa zakres niektórych funkcji Apigee. Na przykład dane mapy klucz-wartość (KVM) mogą być udostępniane na poziomie organizacji, co oznacza, że serwery proxy interfejsów API wdrożone w dowolnym środowisku będą otrzymywać te same dane z tej maszyny wirtualnej. Niektóre funkcje, takie jak zapisywanie w pamięci podręcznej, można ograniczyć do organizacji lub jej konkretnego środowiska. Dane analityczne Apigee są partycjonowane według organizacji i środowiska.
Poniżej znajdują się główne jednostki, którymi zarządzasz w organizacji, w tym te zdefiniowane globalnie w organizacji oraz specjalnie zdefiniowane dla środowiska:
