Jak działają sieciowe interfejsy API? [Zamknięte]

Słyszałem o wielu internetowych interfejsach API, takich jak Facebook, Twitter itp., Które pomagają stronom trzecim uzyskiwać dostęp do danych i nimi manipulować. Chciałbym wiedzieć, jak działa internetowy interfejs API. Jakie są podstawy internetowego interfejsu API?

Jeśli chcę utworzyć interfejs API dla mojej witryny, aby użytkownicy mogli uzyskać do niego dostęp lub go aktualizować, od czego muszę zacząć?

W najprostszym przypadku tworzysz zestaw żądań GET / POST, do których każdy może dzwonić i publikować informacje na adresach URL, parametrach i efektach. Żądania GET dla zadań tylko do odczytu i żądania POST dla wszystkiego, co zmieni dane na serwerze.

Dodaj system uwierzytelniania, jeśli to konieczne, a będziesz mieć prosty interfejs API sieci Web.

Web API jest tylko interfejs , aby umożliwić dostęp do systemu (takich jak strony) za pomocą standardowych metod żądania HTTP . Same dane są zwykle pakowane w jakiś standardowy format (taki jak JSON lub XML ), aby ułatwić ich obsługę.

Oto przykład interfejsu API sieci Web dla „TextWise”

Obecnie opracowuję interfejs API dla platformy wirtualizacyjnej mojej firmy. Możesz obchodzić się z nimi na kilka różnych sposobów, ale moim ulubionym (i najszybszym sposobem na uzyskanie czegoś, co ludzie mogą zrozumieć) jest używanie prostych żądań HTTP GET i zwracanie odpowiedzi JSON.

Mój adres URL wygląda mniej więcej tak:

domain.com/method/call/subcall?key=key&data=something

Następnie rozkładam zmienne HTTP GET i robię z nimi to, co chce osoba dzwoniąca. Jednym z największych powodów, dla których zarejestrowałem się jako użytkownik wersji beta interfejsu API Stack Exchange, było to, że wiedziałem, że będzie to wspaniałe doświadczenie edukacyjne i rzeczywiście tak było .

Zwykle zwracam dwie tablice zakodowane w JSON, z których jedna jest resultpo prostu informacją, czy wywołanie zakończyło się powodzeniem, i podaje kod błędu / ciąg błędu, jeśli nie. Drugi jest zwykle wywoływany data, a jego zawartość jest opisana w dokumentacji tego konkretnego wywołania. Ponadto API oparte na GET są znacznie łatwiejsze do testowania i debugowania.

Istnieje wiele innych formatów, takich jak SOAP / XMLRPC, po prostu stwierdzam, że wybór JSON daje mi niesamowitą prostotę i swobodę wyboru.

Na przykład, jeśli muszę wysłać wiele pól i nie chcę zajmować się mnóstwem zmiennych GET, mogę to po prostu zrobić (przykład w PHP)

$to_send = base64_encode(json_encode($some_array));

Z drugiej strony jest to łatwe do odkodowania, co daje mi dziesiątki zmiennych do pracy, a jednocześnie akceptuje tylko 2-3 zmienne GET za pośrednictwem interfejsu API.

Po prostu staram się, aby moje metody i połączenia były krótkie i zwięzłe, i zaprojektowałem je w taki sposób, aby każde połączenie zwróciło jednolitą odpowiedź „działającą lub nieudaną”, a następnie żądane dane.

To właściwie bardzo szerokie pytanie. W najbardziej podstawowym znaczeniu interfejs API sieci Web działa, gdy klient (np. Przeglądarka internetowa) wysyła jakieś żądanie HTTP do serwera sieci Web. Serwer analizuje to żądanie, aby dowiedzieć się, czego chce użytkownik, a następnie zwraca dane w jakimś formacie (np. Stronie), który następnie sprawdza, aby uzyskać to, czego chce. Są to jedyne rzeczy, które mają wspólne interfejsy API sieci Web; Zdaję sobie sprawę, że to tak naprawdę nie odpowiada na twoje pytanie, ale chciałem podać powód, dla którego pytanie jest tak szerokie.

Istnieje wiele sposobów, w jakie klient może sformatować swoje żądanie lub serwer może sformatować swoją odpowiedź, więc aby którekolwiek z nich miało sens, klient i serwer muszą uzgodnić kilka podstawowych zasad. Ogólnie rzecz biorąc, obecnie istnieją dwa bardzo ogólne style, które przyzwyczajają się do tego rodzaju rzeczy.

Zdalne wywołanie procedury (RPC)

W interfejsie API w stylu RPC zwykle istnieje tylko jeden adres URL dla całego interfejsu API. Nazywasz to POST, jakimś dokumentem zawierającym informacje o tym, co chcesz zrobić, a serwer zwraca dokument zawierający to, co chcesz. Ogólnie rzecz biorąc, dokument żądania ma zazwyczaj nazwę funkcji i kilka argumentów.

Niektóre standardy dla tego stylu API obejmują XML-RPC i SOAP. Standardy te próbują utworzyć format, którego można użyć do opisania wywoływanych funkcji, a nawet do opisania całego interfejsu API.

REpresentational State Transfer (REST)

W interfejsie API w stylu REST nie ma tak wiele adresu URL interfejsu API, jak przestrzeń nazw : serwer lub folder wewnątrz serwera, na którym znajduje się wiele różnych obiektów, a każdy adres URL w tej przestrzeni nazw staje się częścią interfejsu API. Zamiast opowiadać serwer, który chcesz użyć API, URL informuje serwer, co chcesz korzystać z interfejsu API na . Następnie używasz metody HTTP i ewentualnie treści żądania, aby wyjaśnić, co chcesz zrobić z tym obiektem: GET (pobierz coś, co już istnieje), POST (stwórz coś nowego), PUT (zamień coś, co już tam jest) lub USUŃ (pozbądź się czegoś, co już tam jest). Istnieje kilka innych czasowników, których możesz użyć, ale są one zdecydowanie najczęstsze.

Do tej pory nie wspomniałem o standardowych formatach REST. Teoretycznie możesz użyć dowolnego formatu. Protokół HTTP przewiduje już powiedzenie, co chcesz zrobić i do czego chcesz to zrobić, więc format treści żądania może być prawie dowolny: pewna reprezentacja obiektu, który chcesz utworzyć lub zastąpić. Ale w praktyce autorzy REST i tak zgadzają się na format, ponieważ trudno byłoby zrozumieć każdy możliwy format.