Wymiana danych pomiędzy wieloma platformami jest w dobie integracji bardziej kluczowa niż kiedykolwiek. Rozważmy sklep internetowy bez integracji. Twoja witryna musiałaby stworzyć systemy do zarządzania kontami użytkowników, subskrypcjami e-mail, przetwarzaniem płatności, wysyłką i innymi zadaniami oprócz zarządzania listą produktów. Byłoby bardziej efektywne, aby zlecić te obowiązki innym dostawcom, ponieważ nie jest to opcja skalowalna.
Interfejsy programowania aplikacji, lub web API, są tym, co programy wykorzystują do komunikowania się ze sobą. API oferują spójny protokół wymiany danych między dwoma programami. Z pomocą interfejsów API Twój sklep internetowy może komunikować się z oprogramowaniem dostawczym, aplikacjami klienckimi, aplikacjami płatniczymi i wszelkimi innymi wymaganymi połączeniami.
Istnieją różne sposoby tworzenia API; jednak jeśli chcesz dodać połączenia programowe do swoich usług, istnieje jedna unikalna technika, z którą powinieneś się zapoznać: Usługi internetowe REST APIs. W tym artykule omówimy przykłady REST API, czym jest REST API, jak działają REST API, do czego służą REST API, historia, jej elementy i więcej.
Czym dokładnie jest interfejs REST API?
Usługi internetowe reprezentacyjnego transferu stanu lub REST APIs są najbardziej standardową praktyką łączenia komponentów w ramach mikroserwisów, ponieważ oferują wszechstronny, przenośny sposób włączania aplikacji. REST to popularny projekt API, który zatrudniamy do interakcji z wewnętrznymi i zewnętrznymi interesariuszami w znormalizowany i przewidywalny sposób.
Użytkownicy aplikacji internetowych często wykorzystują usługi internetowe REST APIs do komunikacji między sobą. Na przykład, pozyskiwanie i przeglądanie szczegółów konta w programie społecznościowym. Przeglądarki REST APIs mogą być postrzegane jako składnia sieci. Klienci internetowi wykorzystują interfejsy API sieciowe w celu zapewnienia i zarządzania dostępem do operacji cyfrowych w miarę wzrostu wykorzystania chmury.
Projektowanie interfejsów API WWW, które umożliwiają klientom łączenie się z cyfrowymi usługami internetowymi, administrowanie nimi i angażowanie się w nie dynamicznie w rozproszonym kontekście, to rozsądna decyzja. Witryny takie jak Google, eBay, Facebook, Amazon i Twitter wykorzystują usługi sieciowe RESTful. Aplikacje klienckie mogą teraz używać REST, aby uzyskać dostęp do tych usług internetowych.
Technologia REST jest preferowana w stosunku do innych powiązanych technologii. Dzieje się tak dlatego, że usługi sieciowe REST zużywają mniejszą szerokość pasma, co czyni je idealnymi dla efficient aktywności online. Usługi internetowe RESTful mogą być również tworzone przy użyciu języków programowania, takich jak JavaScript czy Python.
Jak działają interfejsy API REST?
Aby wiedzieć, jak działają interfejsy API REST, musimy zdefiniować kilka kluczowych pojęć:
Klient
Użytkownik interfejsu API jest określany jako klient. Klient wysyła zapytania do webowych interfejsów API, aby uzyskać dane lub zastosować modyfikacje w programie. Twoja przeglądarka internetowa jest klientem; komunikuje się z różnymi web API w celu uzyskania zawartości strony. Komputer użytkownika otrzymuje wymagane informacje, które są następnie wyświetlane na ekranie.
Poniżej przedstawiono najpopularniejsze metody HTTP:
- Użyj żądania GET, aby zwrócić żądane dane lub żądane zasoby.
- Użyj żądania POST, aby utworzyć nowy zasób
- Użyj polecenia PUT, aby wprowadzić zmiany lub stale aktualizować istniejący zasób
- Użyj polecenia DELETE, aby pozbyć się zasobu.
Na przykład żądanie HTTP do interfejsu API serwisu Youtube może być zasobem żądania GET dla określonego filmu lub postu albo żądaniem POST w celu opublikowania nowego zdjęcia. Możesz użyć metody żądania POST, aby opublikować nowe posty. Odpowiednio, platforma usług internetowych dla klientów, która integruje się z implementacją auto-attendant, może zatrudnić instrukcję PUT, aby zaktualizować lub wyeliminować niestandardowe przywitanie.
Żądanie Get
- Buforowanie żądań GET jest możliwe.Historia przeglądarki zawiera żądania GET.
- Możliwe jest dodawanie żądań GET do zakładek.
- Nigdy nie używaj żądań GET podczas pracy z materiałami krytycznymi.
- Istnieją ograniczenia długości dla żądań GET.
- Tylko zapytania o dane są wykonywane poprzez żądania GET.
Metoda POST
Żądanie POST jest metodą wysyłania informacji do serwera w celu dodania lub aktualizacji zasobów. Ciało żądania HTTP zawiera dane, które są publikowane po stronie serwera:
- Żądania POST metoda POST nigdy nie trafiają do pamięci podręcznej.
- Żądania POST nie są przechowywane w historii przeglądarki.
- Żądania POST nie mogą być umieszczane w zakładkach
Ciało odpowiedzi
Ciało odpowiedzi jest jednym z ważnych elementów RESTful API. Żądane dane są zawarte w ciele odpowiedzi. Ciało odpowiedzi może zawierać dane dotyczące portów logiki wyjścia i wyjścia.
Zasób
Wszelkie dane, które web API mogą dać użytkownikowi są zasobami. Na przykład, osoba, strona, zdjęcie lub uwaga mogą być uważane za zasoby w API Facebooka. Identyfikator zasobu to specjalny termin nadany każdemu zasobowi.
Serwer WWW
Program, który przyjmuje ciało żądania klienta, używa serwera WWW, który mieści zasoby, o które prosi konsument. Serwer może komunikować się z klientami za pośrednictwem interfejsu API, nie oferując klientom natychmiastowego dostępu do informacji przechowywanych w jego bazach danych. Gdy użytkownik uzyskuje dostęp do usług internetowych RESTful w celu przesłania ciała żądania, serwer wysyła do przeglądarki znormalizowane zobrazowanie stanu zasobu.
Oznacza to, że serwer w jakiś sposób nie przekazuje klientowi dokładnego zasobu, ale raczej odzwierciedla jego stan, czyli sytuację zasobu w określonym czasie. Aby wspomóc zrozumiałość, odpowiedzi zwracane są w lekkim formacie.
JSON (JavaScript Object Notation) jest szeroko stosowany, ponieważ jest czytelny zarówno dla ludzi, jak i maszyn oraz doskonale sprawdza się w promowaniu dostępności stron internetowych. JSON jest głównie używany do wysyłania ciała żądania w aplikacjach internetowych i aplikacjach klienckich. Jest to forma kompatybilna z różnymi sposobami kodowania. Formaty danych API inne niż JSON obejmują XML, YAML, CSV, HTML i zwykły tekst. Użytkownicy interfejsów API mogą wybrać dowolny format danych, używając niestandardowych typów mediów.
Historia interfejsów API REST
Wielu programistów musiało pracować z SOAP przed REST, aby włączyć interfejsy API. Budowanie, wykorzystywanie i debugowanie SOAP było notorycznie trudnym zadaniem. Na szczęście REST został opracowany przez zespół programistów pod kierunkiem Roya Fieldinga, na zawsze zmieniając środowisko API.
Oto chronologia rozwoju interfejsów API REST w czasie:
Przed REST.
Programiści ręcznie napisali plik XML zawierający zdalne wywołanie procedury (RPC) wewnątrz treści, aby połączyć webowe API za pomocą SOAP. Po tym projektanci POSTOWAŁBY swój pakiet SOAP do określonego punktu końcowego.
W 2000 r.
Zespół programistów kierowany przez Roya Fieldinga postanowił opracować ramy umożliwiające dowolnemu serwerowi komunikację z dowolnym innym serwerem. Ułożył on ograniczenia dla interfejsów API REST. Ponieważ te wytyczne są uniwersalne, tworzenie oprogramowania jest łatwiejsze.
W 2002 r.
eBay opracował swój RESTful API w 2002 roku, otwierając swój rynek na każdą stronę internetową, która mogłaby z niego skorzystać. Z tego powodu inny tytan handlu elektronicznego, Amazon, zainteresował się nim i w 2002 roku wydał swój RESTful API.
W latach 2004-2006 r.
RESTful usługi internetowe Flickr zostały wydane w 2004 roku, pozwalając pisarzom na szybkie dodawanie zdjęć do swoich stron internetowych i postów w mediach społecznościowych. Kiedy Twitter i Facebook zauważyli, że znaczna liczba programistów skanuje strony internetowe i tworzy "Frankenstein" API, obaj ujawnili swoje API około dwóch lat później.
W roku 2006-obecnie
Usługi internetowe RESTful są obecnie szeroko akceptowane przez programistów, którzy używają ich do poprawy wydajności swoich aplikacji i stron internetowych. AppMaster ułatwia współpracę i ułatwia konstruowanie interfejsów API, pozwalając na to szybciej.
Do czego wykorzystywane są interfejsy API REST?
Jedną z głównych zalet usług internetowych RESTful jest to, że oferują one dużą elastyczność, co pozwala na bardziej efektywne wykorzystanie tego RESTful API. Poniżej przedstawiamy kilka przykładów tego, do czego wykorzystywane są REST API.
Aplikacje oparte na chmurze
Ze względu na bezpaństwowość swoich połączeń, REST API są korzystne w aplikacjach chmurowych. Bezstanowo działające moduły można łatwo przeinstalować i powiększyć, aby spełnić wymóg przepustowości, jeśli coś pójdzie nie tak. Program łączący komponenty lokalne i internetowe to aplikacja w chmurze. Ten paradygmat wykorzystuje odległe serwery, do których dostęp uzyskuje się za pomocą przeglądarki internetowej i bieżących internetowych usług sieciowych w celu wykonania instrukcji.
Tradycyjną lokalizacją hostów aplikacji w chmurze jest odległy system komputerowy prowadzony przez zewnętrznego operatora sieci cloud computing. Poczta, udostępnianie i przechowywanie dokumentów, wprowadzanie zamówień, kontrola zapasów, Microsoft Word, zarządzanie relacjami z klientami(CRM), gromadzenie informacji oraz finanse i księgowość to przykłady zadań wykonywanych za pomocą aplikacji w chmurze.
Interfejsy programowania aplikacji(API) REST mogą być używane do łączenia zewnętrznych źródeł informacji i zasobów pamięci masowej. Programiści mogą uczynić aplikacje w chmurze mniejszymi, używając interfejsów API REST do przesyłania danych do innych programów w celu obsługi lub analizy obliczeń i zwrócenia wyników do programu. Przetestowane interfejsy API wymuszają aktywną jednolitość, co może przyspieszyć produkcję i przynieść realne rezultaty.
Doskonałym przykładem aplikacji w chmurze jest Google Docs lub Office 365. Wszystko, czego potrzebujesz do korzystania z Google Docs lub Office 365, to komputer, który może uruchomić wyszukiwarki i internetowe usługi internetowe. Sieci komputerowe zapewniają interfejs użytkownika i operacje, w tym przechowywanie informacji. Liczne odrębne aplikacje w chmurze mogą być hostowane przez firmę za pomocą hostów aplikacji w chmurze.
Usługi w chmurze
Ponieważ musiałbyś zarządzać sposobem przetwarzania adresu URL, aby połączyć się z zasobem za pośrednictwem interfejsu API, interfejsy API REST są również przydatne w usługach internetowych w chmurze. Architektura usług internetowych RESTful prawdopodobnie stanie się teraz standardem w przyszłości ze względu na aplikacje w chmurze. Programiści używają usług internetowych RESTful do łączenia się z usługami w chmurze za pomocą internetu. Programista tworzy kod, który wykorzystuje API dostawcy internetowego, podaje niezbędne dane wejściowe i zmienne, a następnie sprawdza odpowiedź, aby upewnić się, że działanie działa zgodnie z oczekiwaniami.
Użytkownicy końcowi mogą uzyskać dostęp do aplikacji klienckich lub usług internetowych oferowanych przez usługi internetowe w chmurze, takich jak infrastruktura obliczeniowa, systemy pamięci masowej lub systemy śledzenia, za pomocą usługi w chmurze, takiej jak usługi internetowe RESTful. API przedstawiają możliwości i operacje aplikacji oraz specyfikę wymaganą do ich wykonania. Aby zachować prywatność i bezpieczeństwo klienta, interfejsy API często zależą od interoperacyjności REST lub Simple Object Access Protocol (SOAP) oraz mechanizmów zezwoleń, takich jak OAuth 2.0.
Różne usługi internetowe są określane jako "usługi w chmurze" i są udostępniane przedsiębiorstwom i konsumentom online na żądanie. Te usługi internetowe są tworzone w celu zaoferowania szybkiego, niedrogiego dostępu do narzędzi i aplikacji bez wymogu posiadania sprzętu lub infrastruktury. Większość pracowników korzysta z usług internetowych w chmurze do wszystkiego, od poczty elektronicznej po współpracę nad dokumentami.
Użycie sieciowe
Te webowe interfejsy API można uzyskać z projektu internetowego użytkownika, aplikacji iPhone, urządzenia IoT lub Windows Mobile, ponieważ REST nie zależy od funkcjonalności po stronie klienta. Możesz stworzyć architekturę dla swojej firmy, nie będąc ograniczonym do konkretnego frameworka po stronie klienta.
Przykład REST API
Omówmy przykład REST API. Kliknij poniższe łącze, aby zadać Open Trivia Database dowolne zapytanie wywiadowcze: Takie usługi internetowe RESTful zostały wykorzystane do udostępnienia publicznego interfejsu API sieciowego. Twój komputer wyświetli samotne pytanie quizowe i jego odpowiedzi w formacie JSON.
Korzystając z dowolnej przeglądarki HTTP, np. url, możesz wydać następujące zapytanie i otrzymać odpowiedź w ciele odpowiedzi: https://opentdb.com/api.php?amount=1&category=18
Ciało odpowiedzi w pliku XML usługi sieciowej będzie zawierało wszystkie informacje o pracowniku.
Wszystkie powszechnie stosowane dialekty programowania i narzędzia deweloperskie posiadają biblioteki klienta HTTP, takie jak retrieve w JavaScript, Node.js i Deno oraz file get content() w PHP. Odpowiedź JSON może być czytana i używana, ponieważ jest czytelna maszynowo przed wyświetleniem w HTML lub innym stylu.
Interfejsy API Rest i REST
Z czasem rozwinęło się wiele metod przesyłania danych. Być może natknąłeś się na wybory takie jak CORBA, SOAP lub XML-RPC. Większość z nich opracowała rygorystyczne wytyczne dotyczące wiadomości. Roy Fielding po raz pierwszy nakreślił REST w 2000 roku, który jest znacznie bardziej prosty niż inne.
Jest to raczej zbiór sugestii i ograniczeń dla usług internetowych RESTful niż norma. Składają się one z następujących ograniczeń architektonicznych:
Partycja klient-serwer.
Klienci i serwery WWW mogą komunikować się tylko w jednym kierunku w ramach architektury REST: klient żąda kontrolera domeny, a kontroler lub serwer odpowiada na żądanie. Serwery internetowe nie mogą składać żądań, a klienci nie mogą reagować; konsument uruchamia wszystkie połączenia.
Usługi internetowe RESTful utrzymują klientów i serwery w izolacji, ułatwiając interakcję między nimi. Komputery klienckie mogą się rozwijać bez obaw o wpływ na inny hosting, a materiały serwerowe mogą być zmieniane bez nieświadomego wpływu na klientów.
Jednolity interfejs
Zgodnie z tą strategią wszystkie zapytania i reakcje muszą stosować się do standardowej procedury prowebowej lub stylizować swoje wiadomości. Aplikacje i serwery są tworzone w różnych językach programowania, które słabo radzą sobie ze sobą za pomocą mediatora. Jednolity interfejs to dialekt, którego każdy klient może użyć do interakcji z dowolnymi interfejsami REST API.
Tłumaczenie żądań i reakcji między aplikacjami z normalizowaną interakcją byłoby możliwe tylko w tym przypadku. Drobne różnice spowodowałyby miszmasz i utratę informacji, a rozwiązania będą musiały uaktualnić swoje procedury żądań, gdy interfejsy API WWW zmodyfikują swoje. Spójny interfejs eliminuje tę perspektywę.
DOSTĘP DO https://www.googleapis.com/youtube/v3/channels?part=contentDetails
Jak wszystkie aplikacje klienckie REST, ta propozycja zawiera dwa elementy danych. Technika HTTP to GET. Opisuje ona akcję, którą klient chce wykonać na zasobach. Użytkownik może wykonać cztery podstawowe metody HTTP:
HTTP, czyli Hyper-Text Transfer Protocol, jest uniwersalnym językiem dla większości interfejsów API REST. HTTP nie został zaprojektowany z myślą o REST. Dodatkowo REST przyjął tę transmisję danych jako kryterium dla aplikacji świadomych REST. W przypadku korzystania z HTTP z interfejsami API REST klient składa żądanie w formacie, który możesz znać. Na przykład zarzut sygnału wideo do API YouTube wygląda tak:
- Użyj polecenia GET, aby uzyskać zasób.
- Użyj polecenia POST, aby utworzyć nowy zasób
- Użyj polecenia PUT, aby wprowadzić zmiany do istniejącego zasobu lub stale go aktualizować
- Użyj polecenia DELETE, aby pozbyć się zasobu.
Metody HTTP określają zamierzone działanie, które ma zostać podjęte dotyczące określonego zasobu. Metody HTTP są również znane jako czasowniki HTTB.
Adres URL to HTTP
Jednolity identyfikator zasobu, lub URI, który identyfikuje zamierzony zasób jest zawarty w adresie URL. Adres URL jest również punktem końcowym w tym scenariuszu, ponieważ jest to miejsce, w którym RESTful API wchodzi w kontakt z użytkownikiem usługi.
Ciąg zapytania: Adres URL zawiera ciąg zapytania. Ciąg zapytania służy do określenia parametrów, którym nadawane są wartości.
Po otrzymaniu i zweryfikowaniu zarzutu serwer WWW zwraca dane dotyczące docelowego zasobu. Zazwyczaj dane są zwracane w strukturze znanej jako JSON (JavaScript Object Notation). JSON przedstawia wszystkie składniki zasobu w przenośnym formacie, który Humani może łatwo odczytać.
Zasady jednolitego interfejsu
Jednolity interfejs musi spełniać następujące parametry:
HATEOAS: Hypermedia jako silnik stanu aplikacji.
Hipermedia jest silnikiem stojącym za usługami internetowymi RESTful. Wskazuje to, że hipermedia jest wszystkim, co klient chce pojąć, aby rozpoznać odpowiedź dostawcy.
- Tylko pierwszy URI aplikacji klienckiej musi być dostarczony do klienta. Aplikacja kliencka powinna stale napędzać wszystkie inne materiały i działania za pomocą hiperłączy.
- Usługi internetowe RESTful nie wymagają języka zapytań wejściowych (IDL), który różni się od innych interfejsów API
Typ mediów to nazwa dla formatu danych reprezentacji. Typ mediów identyfikuje definicję, która nakreśla, jak należy traktować zobrazowanie. Web API, które wykorzystuje REST, wydaje się być hipertekstem. Każdy element danych, do którego można się odnieść, nosi lokalizację, albo bezpośrednio (jak np. poprzez właściwości link i identity), albo niejawnie (np. pochodzącą ze struktury opisu typu mediów).
Wiadomości samoopisowe
Każda komunikacja pomiędzy stroną klienta a stroną serwera powinna dostarczać wystarczającą ilość danych do wykonania komunikacji. W związku z tym, żądanie od strony klienta do strony serwera musi określać zasób, do którego próbuje uzyskać dostęp wraz z jego konkretnymi celami.
Dodatkowo, przedstawienia zasobów muszą być samoopisowe; użytkownik nie musi być świadomy, czy zasób jest osobą, czy elementem wyposażenia. Zamiast tego powinien reagować zgodnie z typem mediów połączonym z pomocą.
Dlatego też, bezsprzecznie, będziemy rozwijać wiele unikalnych typów mediów, często jeden typ mediów na zasób. Każda forma mediów określa standardowy paradygmat produkcji. Na przykład, HTML definiuje jak hipertekst jest wyświetlany i jak przeglądarka obsługuje każdy element.Identyfikacja zasobów
Zasoby, o których mowa w tylnej komunikacji między klientem a serwerem muszą być rozpoznawalne za pomocą obrazków. Trzymanie się systemu Uniform Resource Identifier (URI) pozwoliło na to. Innymi słowy, komunikacja z serwera do klienta może zawierać wersję HTML dokumentu i kilka informacji, a nie prawdziwy plik z magazynu serwera.
Konsument może łatwo zrozumieć wersję HTML, ponieważ jest ona zgodna ze wzorcem URI. Klient musi modyfikować zasoby, przekazując serwerowi wyobrażenie o tym, jak zasób powinien się ostatecznie pojawić. Dzięki temu użytkownik mógłby budować, pobierać, modyfikować i usuwać zasoby. Jeśli klient ma niezbędne uprawnienia do zmiany danych, serwer powinien spełnić zapytanie.
Bezstanowa
W przypadku RESTful API wszystkie żądania klienta muszą być przejściowe. W rezultacie każde zapytanie i ciało odpowiedzi zawierają wszystkie dane wymagane do zawarcia umowy, dzięki czemu każde połączenie jest autonomiczne. Serwer nie śledzi poprzednich żądań HTTP; traktuje każde wykonane przez klienta jako zupełnie nowe zapytanie.
Ponieważ serwer nie musi wykonywać żadnych dodatkowych zadań, aby uzyskać dane historyczne, transporty bezstanowe znacznie minimalizują ilość pamięci masowej niezbędnej dla serwera i zwiększają prawdopodobieństwo, że odpowiedź będzie akceptowalna. Gwarantuje to skalowalność tych interakcji: programiści nie muszą się martwić, że zużyją znacznie więcej pamięci masowej lub obciążą serwer, gdy ich oprogramowanie rozrośnie się i wykona żądania HTTP.
Warstwowa strona
Dotychczas definiowaliśmy zapytania Web API jako prostą wymianę klient-serwer, choć jest to nieco zbytnie uproszczenie. Pomiędzy tymi dwoma organizacjami często znajduje się więcej serwerów. Te platformy, lub warstwy, są na miejscu, aby zarządzać i rozpraszać ruch, dodawać ochronę i wykonywać różne inne kluczowe zadania.
Zgodnie z tą koncepcją, wiadomości przesyłane między użytkownikiem a serwerem docelowym muszą być ustrukturyzowane i obsługiwane podobnie, niezależnie od warstw, które istnieją pomiędzy nimi. Dodatkowe warstwy powinny być w porządku w przypadku interakcji z klientami. Programiści, którzy przestrzegają tej zasady, mogą zmieniać systemy serwerów bez wpływu na podstawowy proces żądanie-odpowiedź.
Cacheable
Buforowanie ma miejsce, gdy klient przegląda stronę internetową, gdy zawartość jest zapisywana na jego komputerze. Materiał zapisany w pamięci podręcznej jest szybko ładowany z pamięci wewnętrznej, zamiast być ponownie pobierany z serwera, gdy użytkownik odwiedza daną witrynę później. Większość dużych witryn używa buforowania w celu zmniejszenia obciążenia strony przy jednoczesnym zachowaniu miejsca na serwerze i przepustowości.
Buforowanie danych jest brane pod uwagę przy tworzeniu interfejsów API REST. Odpowiedź, którą serwer daje klientowi, powinna określać, czy i przez jaki czas dany zasób może być przechowywany.
Kod na żądanie
Ostatni dogmat REST jest zbędny. Odpowiedź API, jeśli jest żądana, może zawierać kod oprogramowania do wykorzystania przez klientów. Z tego powodu klient może wykonać aplikację kliencką lub program w swoim backendzie.
API jest uważane za RESTful API, jeśli jest zgodne z tym zestawem wytycznych. Te wytyczne dają jednak programistom dużą swobodę w modyfikowaniu funkcji ich RESTful API. REST API różnią się od Simple Object Access Protocol, innej popularnej techniki Web API, tym, że są bardziej elastyczne (SOAP).
Konsensus punktów końcowych
Weź pod uwagę te punkty końcowe:
- /user/123str.
- /user/id/123
- /user/123\s/user/id/123\s
- /user/?id=123
Wszystkie są uzasadnionymi metodami dla klienta 123 do pobierania danych. Gdy pojawiają się bardziej skomplikowane procedury, liczba możliwości rośnie. Na przykład w odwrotnej kolejności, zaczynając od wpisu 51, wyświetl 10 osób o nazwiskach zaczynających się od "A", które działają dla firmy.
W końcu nie obchodzi, jak strukturyzujesz adresy URL; jednolitość w całym twoim RESTful API ma znaczenie. W ogromnych systemach oprogramowania z wieloma programistami, to nie może być łatwe. Modyfikacje RESTful API są nieuniknione, ale adresy URL punktów końcowych nigdy nie mogą być odrzucane, ponieważ robienie tego spowoduje, że aplikacje, które na nich polegają, przestaną działać.
Wersjonowanie API REST
Wersjonowanie interfejsów API jest powszechną praktyką zapobiegającą niekompatybilności. Jako ilustracja, /2.0/user/123 zastępuje /user/123. Zarówno stary, jak i nowy punkt końcowy mogą nadal działać. W konsekwencji wymusza to konieczność utrzymania ważnych API z przeszłości. Poprzednie wersje mogą ostatecznie zostać wycofane, ale procedura musi być dokładnie przemyślana.
Uwierzytelnianie interfejsu API REST
Każde urządzenie może pobrać quip bez autoryzacji za pomocą interfejsu API zapytania. Interfejsy API, które odczytują prywatne informacje lub umożliwiają edycję i usuwanie zapytań, nie obsługują tego. Programy po stronie klienta w tej samej domenie co usługi internetowe RESTful są wysyłane i otrzymują pliki cookie w taki sam sposób jak żądania HTTP. (Należy pamiętać, że opcja restartu uprawnień musi być określona we wcześniejszych serwisach dla Fetch()). Zapytanie API może zostać zweryfikowane w celu potwierdzenia, że użytkownik jest zalogowany i ma wymagane uprawnienia.
Podstawowe uwierzytelnianie HTTP: Programy stron trzecich muszą używać różnych rozwiązań zatwierdzających. Niektóre popularne metody uwierzytelniania to weryfikacja podstawowa dla:
- HTTP. Zakodowany w base64 ciąg nazwa użytkownika: hasło jest podawany w polu zapytania jako część nagłówka HTTP Approval.
- Klucze API: Poprzez podanie klucza RESTful API, który może mieć specjalne uprawnienia lub być ograniczony do pojedynczej witryny, udostępnia się interfejs API aplikacjom stron trzecich. Każda wiadomość zawiera klucz albo w ciągu zapytania, albo w nagłówku HTTP. (Ciąg zapytania jest składnikiem adresu URL).
- OAuth: Przed wykonaniem jakichkolwiek żądań, identyfikator klienta i być może sekret klienta są wysyłane do serwera OAuth, aby uzyskać poświadczenie. Do czasu jego wygaśnięcia tożsamość OAuth jest następnie przekazywana wraz z każdym żądaniem API.
- Tokeny internetowe w JSON (JWT): Nagłówek zapytania i nagłówek odpowiedzi bezpiecznie przekazują cyfrowo podpisane dane uwierzytelniające użytkownika. JWT umożliwiają serwerowi szyfrowanie uprawnień dostępu, eliminując potrzebę zapytania do bazy danych lub użycia innego mechanizmu uwierzytelniania.
Scenariusz użycia będzie miał wpływ na sposób uwierzytelniania interfejsu API:
- Czasami program strony trzeciej jest obsługiwany jak każdy inny zalogowany klient z tymi samymi uprawnieniami i prawami. Na przykład interfejs API mapy może dostarczyć programowi żądającemu instrukcji między dwoma miejscami. Musi on zweryfikować, czy program jest prawowitym użytkownikiem, ale nie musi sprawdzać poświadczeń klienta.
- W innych sytuacjach program strony trzeciej prosi o informacje osobiste od konkretnego użytkownika, takie jak zawartość poczty. Interfejsy API REST muszą rozpoznać klienta i jego uprawnienia, ale nie muszą się przejmować programem wywołującym.
Bezpieczeństwo interfejsów API REST
Usługi sieciowe RESTful dodają kolejny sposób na interakcję i wpływ na Twoje oprogramowanie. Nawet jeśli twój host nie jest podwyższonym celem hakerskim, źle zachowujący się użytkownik może przesłać setki żądań na sekundę i zawalić go. Ten artykuł nie obejmuje bezpieczeństwa, ale standardowe najlepsze procedury obejmują:
Korzystaj z protokołu HTTPS
Zastosuj silny mechanizm uwierzytelniania
CORS może być używany do ograniczania połączeń klientów do określonych obszarów.
Zapewnij niezbędne możliwości - to znaczy, nie
Generowanie wyborów DELETE, które nie są konieczne; sprawdź wszystkie adresy URL punktów końcowych i informacje o ciele.
Blokuj linki z niezidentyfikowanych sektorów lub adresów IP, nie poddając kuponów API w JavaScript po stronie klienta.
Nienormalnie duże pakiety są blokowane.
Pomyśl o ograniczeniu stawki, gdzie żądania z tego samego adresu IP lub poświadczenia API są ograniczone do N zapytań na minutę.
Odpowiedź z właściwym kodem statusu HTTP, zapytania z nagłówkiem cache'a i nieudane śledztwo
Wielokrotne żądania i niepotrzebne dane
Wdrożenie usług internetowych RESTful ma ograniczenia. Możliwe jest, że odpowiedź zawiera więcej informacji niż żądałeś lub że wymagane jest wiele żądań, aby uzyskać wszystkie informacje. Pomyśl o usługach internetowych RESTful, które dają użytkownikom dostęp do informacji o twórcy i książce; klient mógłby:
- Poprosić o informacje o pierwszych 10 książkach, wymienionych w kolejności zakupu (najpierw top seller). Zbiór książek, wraz z identyfikatorem każdego pisarza, jest zawarty w odpowiedzi.
Aby pobrać informacje dla każdego pisarza, zbuduj do 10 zapytań /author/id.
N zapytań API powinno być wygenerowane dla każdej odpowiedzi na zapytanie nadrzędne, scharakteryzowane jako "N+1 problem."
Jeśli jest to sytuacja częstego użycia, usługi internetowe RESTful mogą zostać zmodyfikowane tak, aby zawierały wszystkie informacje o pisarzu dla każdej książki, którą wyprodukował, w tym nazwisko, płeć, narodowość, biografię i tak dalej. Nawet więcej informacji o ich poprzednich książkach może być dostarczonych, choć zrobienie tego znacznie zwiększyłoby obciążenie odpowiedzi. API może zostać zmienione tak, aby informacje o pisarzu były opcjonalne. Author details=full, aby zapobiec niepotrzebnie dużym odpowiedziom. Sama liczba opcji, które projektanci API muszą wspierać, może być przytłaczająca.
Podsumowanie
Teraz dokładnie rozumiesz interfejsy REST API, sposób działania interfejsów REST API, przykłady interfejsów REST API, do czego służą interfejsy REST API, ograniczenia architektoniczne i inne tematy poruszane w tym samouczku. Programiści mogą uważać naukę o API za trudną i onieśmielającą, ale platforma no-code AppMaster stworzyła nową przystępną bibliotekę REST APIs, w której możesz pogłębić swoją wiedzę o szeregu REST APIs, aby wspierać swój dalszy rozwój zawodowy.
W AppMaster staramy się zwiększać dostępność i użyteczność API. Chcemy, abyś poznał, eksperymentował i uświadomił sobie korzyści płynące z używania oprogramowania API w swojej karierze i życiu osobistym. Aby pomóc Ci szybciej projektować lepsze webowe API, AppMaster usprawnia współpracę i automatyzuje każdy etap cyklu życia API. Nieustannie twórz, rozwijaj i poszerzaj swoją wiedzę na temat interfejsów API REST.
