Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info
Organizacja jest najwyższym kontenerem w Apigee Edge. Zawiera wszystkie Twoje proxy interfejsu API i powiązane zasoby. Chociaż reszta tego tematu dotyczy bardziej szczegółowo organizacji, oto kilka praktycznych wskazówek:
- Domyślnie nazwa Twojej organizacji znajduje się w adresie URL służącym do wywoływania serwerów proxy interfejsu API zgodnie z opisem w artykule 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 proksy interfejsu API dla organizacji
docs:
- Możesz mieć utworzoną tylko jedną organizację, ale możesz należeć do innych organizacji jako użytkownik lub administrator z określonymi uprawnieniami. Jeśli w interfejsie zarządzania w Edge należysz do więcej niż 1 organizacji, możesz przełączyć się na inną organizację w sposób opisany w artykule Przełączanie się między organizacjami.
- Gdy wykonujesz wywołania interfejsu Management API jako użytkownik o roli Administrator organizacji, organizacja jest wymaganą częścią ścieżki w większości wywołań. Na przykład to żądanie cURL interfejsu API do zarządzania 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ę wielodzierżalności na potrzeby 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 i usługi API oraz rejestrować deweloperów i aplikacje.
Ilustracja poniżej przedstawia główne elementy modelu organizacyjnego Edge. Ten model określa, jak interfejsy API, produkty API, aplikacje i ich deweloperzy są powiązane w Edge.
Ten model nie wyświetla wszystkich funkcji Apigee Edge. Jeśli korzystasz z zarabiania, model będzie zawierać dodatkowe komponenty. Więcej informacji znajdziesz w artykule Omówienie zarabiania. Informacje o zarządzaniu firmami i deweloperami przy użyciu funkcji zarabiania znajdziesz w artykule Zarządzanie firmami i deweloperami.
nazwy organizacji;
Nazwa organizacji:
- Organizacja przeprowadzająca ocenę:
username-eval - Płatna organizacja: definiowana przez użytkownika w momencie wstępnego założenia.
Po utworzeniu nie możesz zmienić nazwy organizacji.
Nazwa organizacji staje się częścią adresu URL Twoich serwerów 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
W tabeli poniżej znajdziesz bardziej szczegółowy opis elementów modelu organizacyjnego:
| Komponent | Opis |
|---|---|
|
Organizacja |
Każde konto Apigee jest powiązane z co najmniej 1 organizacją w Apigee Edge. Organizacja zawiera wszystkie komponenty, w tym serwery proxy interfejsów API, usługi API, pakiety interfejsów API, aplikacje i deweloperów. Posiadacze kont nie są ograniczeni do jednej organizacji. Niektórzy właściciele kont mogą definiować lub być członkami wielu organizacji, które wspierają różne społeczności deweloperów aplikacji. |
| Środowisko | Kontekst wykonywania w czasie wykonywania 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 należą do zespołu organizacji ds. interfejsów API, do którego mogą należeć m.in. administratorzy, twórcy serwerów proxy i API usług API oraz użytkownicy monitorujący statystyki i inne statystyki. Różni użytkownicy mogą mieć różne role i uprawnienia dostępu. Na przykład możesz określić, że niektórzy użytkownicy mają uprawnienia Administratora organizacji i Administratora operacji, które umożliwiają im modyfikowanie organizacji i jej komponentó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, które będą wspierać różne społeczności programistów. Wewnętrznie te same osoby tworzą wszystkie proxy i produkty API, a zatem są członkami wszystkich Twoich organizacji. Aby zostać 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 serwer proxy interfejsu API. Serwer proxy interfejsu API definiuje mapowanie publicznie dostępnego punktu końcowego HTTP na usługę backendu. Proxies API można też skonfigurować tak, aby uwzględniały zabezpieczenia (np. OAuth), przeprowadzały transformację wiadomości (np. XML na JSON), ograniczały ruch do usług backendowych i wykonywały inne przydatne operacje na żądaniu, odpowiedzi i wywołaniach usług. Edge zbiera dane do celów analitycznych w przypadku serwerów proxy interfejsu API. |
|
Usługa API |
Użytkownicy w organizacji tworzą co najmniej 1 usługę API, która jest pakietem zastępników interfejsu API połączonym z planem usług. Ten plan usługi może określać limity dostępu do serwerów proxy interfejsu API, zapewniać bezpieczeństwo, umożliwiać monitorowanie i analizowanie oraz udostępniać dodatkowe funkcje. Edge gromadzi dane na potrzeby analiz usług API. |
|
Deweloper |
Organizacja zawiera co najmniej 1 programistę, który tworzy aplikacje korzystające z interfejsów API (zmontowanych w produkty API) zdefiniowanych przez Twoją organizację. Programiści korzystają z interfejsów API, ale nie mogą ich tworzyć ani wykonywać żadnych innych działań w organizacji. Mogą to być wewnętrzni partnerzy Twojej firmy lub zewnętrzni deweloperzy, którzy płacą za dostęp do Twoich interfejsów API. Aby móc zarejestrować aplikację i otrzymać klucz interfejsu API umożliwiający dostęp do Twoich interfejsów API, deweloperzy muszą być zarejestrowani w Twojej organizacji. Jako dostawca interfejsu API decydujesz, w jaki sposób dodawać, aktualizować i usuwać deweloperów w swojej organizacji. Możesz je dodawać ręcznie w interfejsie zarządzania Edge, utworzyć portal dla deweloperów, aby rejestrować je za pomocą witryny, 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 musi znać niczego na temat Edge. Jeśli deweloper ma konto w Edge, jest to zazwyczaj konto użytkownika w innej organizacji lub do korzystania z usług interfejsu API Edge. |
|
Promująca aplikację |
Programiści tworzą co najmniej 1 aplikację klienta, która korzysta z Twoich interfejsów API. Deweloperzy muszą zarejestrować swoje aplikacje w Twojej organizacji. Aplikacja na urządzeniu Edge reprezentuje rzeczywistą aplikację dewelopera, która dostarcza mu klucz interfejsu API, który może być przekazywany przy każdym żądaniu do Twoich interfejsów API. Wszystkie aplikacje są zarejestrowane w Twojej organizacji, dlatego możesz używać Edge do monitorowania i gromadzenia informacji analitycznych na temat aplikacji oraz korzystania przez nią z Twoich interfejsów API. |
|
Klucz API lub token OAuth |
W zależności od mechanizmu autoryzacji zdefiniowanego dla interfejsów API aplikacja przekazuje klucz interfejsu API wraz z każdym żądaniem do interfejsów API. Jeśli ten klucz jest prawidłowy, żądanie jest dozwolone. Edge obsługuje różne typy uwierzytelniania, takie jak prosty klucz API, dwuetapowa autoryzacja OAuth, trzyetapowa autoryzacja OAuth i inne. Jako dostawca interfejsu API musisz określić sposób, w jaki deweloperzy mogą rejestrować swoje aplikacje. Rejestrując aplikację, zwracasz deweloperowi klucz wymagany do uzyskania dostępu do Twoich interfejsów API. Podczas rejestracji aplikacji deweloper może wybrać dostęp do jednego produktu interfejsu API lub do wielu produktów interfejsu API. Rzeczywista aplikacja dewelopera używa tego samego klucza do uzyskiwania dostępu do wszystkich usług API powiązanych z aplikacją (zarejestrowana reprezentacja aplikacji dewelopera w Edge). W dowolnym momencie możesz wycofać 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 czasowy dla klucza, aby deweloper musiał go odświeżyć po upływie określonego czasu. |
Informacje o środowiskach
Środowisko to środowisko wykonawcze proxy interfejsu API w organizacji. Zanim będzie można uzyskać dostęp do serwera proxy API, musisz go wdrożyć w środowisku. Możesz wdrożyć serwer proxy interfejsu API w jednym środowisku lub w kilku ś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) można udostępnić na poziomie organizacji, co oznacza, że serwery proxy interfejsów API wdrożone w dowolnym środowisku otrzymują 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ą partycjonowane przez kombinację organizacji i środowiska.
Poniżej znajdziesz główne elementy, którymi zarządzasz w organizacji, w tym te zdefiniowane globalnie w organizacji i te zdefiniowane specjalnie dla środowiska:
