Podstawy REST i RESTful API Development

Twórcy stron internetowych często o tym mówią Zasady REST i architektura danych RESTful, ponieważ jest to kluczowy aspekt nowoczesnego rozwoju, ale czasami może być niewiarygodnie mylący. REST nie jest technologią samą w sobie, ale raczej metoda tworzenia API z pewnymi zasadami organizacyjnymi. Zasady te mają pomóc programistom i stworzyć bardziej uniwersalne środowisko do przetwarzania żądań API.

W tym poście chciałbym wyjaśnić praktyki rozwoju RESTful z lotu ptaka. Chcę się zająć co niż w jaki sposób. Chociaż będę poruszał się w obu obszarach, ten post jest przeznaczony dla każdego, kto zajmuje się tworzeniem stron internetowych, ale po prostu nie może pojąć pojęcia API REST.

REST dla programistów internetowych

Skrót REST oznacza Reprezentatywny transfer państwowy. Może to brzmieć nieco myląco, a wpis wiki sprawia, że ​​brzmi to jeszcze bardziej myląco. Ale możliwe jest uproszczenie terminologii.

REST to tylko seria wytyczne i style architektoniczne wykorzystywane do transmisji danych. Jest powszechnie stosowany do aplikacji internetowych, ale może również przekazywać dane do oprogramowania.

Skrót API to skrót od Application Programming Interface, czyli metody programowania aplikacji łączenie z innymi bibliotekami lub aplikacjami. Windows ma wiele interfejsów API, a Twitter ma również API WWW, chociaż wykonują różne zadania o różnych celach.

Łącząc to wszystko, interfejsy API RESTful są interfejsami API zgodnymi z architekturą REST.

Czym dokładnie jest architektura REST?

W tym miejscu trudno jest określić szczegóły. Istnieją jednak pewne stałe architektoniczne, takie jak:

• Konsystencja w całym interfejsie API
• Bezpaństwowe istnienie, tj. brak sesji po stronie serwera
• Zastosowanie Kody statusu HTTP w stosownych przypadkach
• Zastosowanie Punkty końcowe URL z logiczną hierarchią
• Wersjonowanie w adresie URL zamiast w nagłówkach HTTP

Nie ma zbyt szczegółowych wytycznych, takich jak specyfikacja W3C HTML5, która mogłaby prowadzić do zamieszania, i miazma niepewności wokół terminologii REST.

Również powyższa lista nie należy uważać za trudne zasady, nawet jeśli są prawdziwe dla większości nowoczesnych API REST.

REST to a lekka metodologia co czyni go idealnym do danych HTTP. Dlatego właśnie REST stał się tak popularny w sieci i dlatego jest powszechnie uważany za najlepszy wybór do rozwoju API.

Jak ujął to Vinay Sahni, “API to interfejs programisty.” Wszystko powinno być łatwe w obsłudze i zapewniać doskonałe wrażenia użytkownika. RESTful API mają na celu właśnie to.

Kluczowe informacje o RESTful API

Te wskazówki są w kontekście interfejsów API ściśle dla aplikacji internetowych. To znaczy że HTTP jest wymaganiem, i często to znaczy dane API są hostowane na zewnętrznym serwerze. Przyjrzyjmy się, jak interfejsy API RESTful działają po stronie użytkownika interfejsu API.

Użytkownik API jest programistą WWW, który może zbudować skrypt, który łączy się z zewnętrznym serwerem API, a następnie niezbędne dane są przekazywane przez HTTP. Deweloper może następnie wyświetlać dane na swojej stronie internetowej bez osobistego dostępu do zewnętrznego serwera (jak ciągnięcie danych z Twittera).

Ogólnie rzecz biorąc są cztery polecenia przyzwyczajony dostęp do API RESTful:

1. DOSTAĆ do pobierania obiektu
2. SŁUPEK do tworzenia nowego obiektu
3. POŁOŻYĆ do modyfikowania lub zastępowania obiektu
4. KASOWAĆ za usunięcie obiektu

Każda z tych metod powinna być przekazane z wywołaniem API powiedzieć serwerowi, co ma robić.

Zdecydowana większość internetowych interfejsów API tylko pozwól DOSTAĆ upraszanie wyciągać dane z zewnętrznego serwera. Uwierzytelnianie jest opcjonalne, ale z pewnością jest dobrym pomysłem, gdy zezwala się na potencjalnie szkodliwe polecenia, takie jak POŁOŻYĆ lub KASOWAĆ.

Jednak niewiele API RESTful idzie nawet tak daleko. Rozważ Pokéapi, który jest darmową bazą danych Pokémon API. Jest otwarty dla publiczności z przyzwoitym ograniczeniem stawek (ograniczenie użytkowników do pewnej liczby żądań API w pewnym okresie czasu), ale zezwala tylko na DOSTAĆ metoda dostępu do zasobów. Może to być potocznie nazywane a API tylko do konsumpcji.

Zwróć typy są również ważne i powinny zachować jednorodność dla wszystkich zasobów. JSON jest popularnym typem powrotu ze specyfikacjami online, które wyjaśniają prawidłowe struktury danych.

Wykorzystanie RESTful API rzeczowniki dla obiektów API, i czasowniki do wykonywania akcji na tych przedmiotach. Uwierzytelnianie może być częścią tego, ograniczenie to może również być częścią tego. Ale bardzo prosty interfejs API może się obejść bez większego zainteresowania ograniczeniami użytkowników.

Dostęp do zasobów API

Publiczne interfejsy API są zazwyczaj dostępne z bezpośrednich adresów stron internetowych. To znaczy struktura adresu URL jest ważna, i powinien być używany tylko dla żądań API.

Niektóre adresy URL mogą zawierać katalog prefiksów, taki jak / v2 / dla zaktualizowanej wersji 2 poprzedniego API. Jest to powszechne dla programistów, którzy nie chcą deprecjonować swojego interfejsu API 1.x, ale nadal chcą oferować najnowszą strukturę.

Naprawdę podobał mi się ten post podstawowe struktury URL i przykłady z innych usług.

Zauważ, że punkty końcowe dane zwrotne ulegną zmianie dramatycznie w oparciu o Metoda HTTP. Na przykład, DOSTAĆ pobiera zawartość SŁUPEK tworzy nową treść. Żądanie może wskazywać ten sam punkt końcowy, ale wynik może być bardzo różny.

Przeglądanie przykładów online może pomóc w lepszym zrozumieniu pojęć. Widzieliśmy już Pokeapi, ale oto kilka innych rzeczywiste przykłady API czytać:

• Reddit API
• GitHub API
• API Flickr
• Pinterest API

Budowanie własnego API

Proces tworzenia własnego API nie powinien być lekceważony, ale nie jest tak skomplikowany, jak mogłoby się wydawać. To bierze zrozumienie wzorców projektowania API i najlepszych praktyk zbudować coś o prawdziwej wartości.

Każde API musi połączyć się z serwerem zwracać jakieś dane. Nie tylko musisz napisać kod, ale musisz także sformatować dane zwrotne. Inne potencjalne wymagania obejmują poświadczenie i ograniczenie stawki, więc budowanie API z pewnością nie jest dla słabych serc.

Ale spójrzmy na to kilka podstawowych zasad architektury API.

Buduj punkty końcowe

Jednym z aspektów rozwoju API jest budowanie punktów końcowych. Gdy tworzenie zasobów chcesz używać rzeczowników, a nie czasowników. Oznacza to, że dane API powinny zwracać osobę, miejsce lub rzecz, najczęściej jest to rzecz o określonych atrybutach (na przykład tweet i wszystkie jego metadane).

Nazywanie rzeczowników może być trudne, ale jest to kluczowy aspekt rozwoju API. Uproszczenie jest najlepsze, gdy jest to możliwe.

Wielka debata jest liczba pojedyncza a liczba mnoga rzeczowniki. Jeśli tworzyłeś API Twittera, możesz najpierw utworzyć grupę obiektów (np. Tweet), a następnie drugi obiekt (tj. Tweet ID).

 $ / tweet / 15032934882934 $ / tweets / 15032934882934 

W tym przypadku twierdzę, że pojedyncza forma wygląda lepiej. Dotyczy to zwłaszcza zwracania tylko jednego zasobu. Ale nie ma udokumentowanej 100% poprawnej odpowiedzi, więc rób to, co najlepiej pasuje do twojego projektu.

Ustaw typ powrotu

Inną kwestią jest zwracać dane typu. Większość użytkowników sieci spodziewa się zawartości JSON, więc jest to prawdopodobnie najlepsza opcja. XML to kolejny wybór, jeśli chcesz zaoferować oba. JSON jest jednak podstawowym typem powrotu API wśród twórców stron internetowych.

W tworzeniu interfejsu API jest znacznie więcej, dlatego polecam najpierw korzystanie z interfejsów API. W ten sposób możesz zobaczyć, jak inni programiści budują swoje interfejsy API i mam nadzieję, że będziesz zaznajomiony z typowymi wymaganiami.

Jeśli dopiero zaczynasz, rozważ przejrzenie tych samouczków dev:

• Witryna samouczka REST API
• Pisanie prostego API REST
• Budowanie RESTful Web Service

Dalsze zasoby

Najlepszym sposobem nauki programowania aplikacji internetowych jest praktyka. Przyznana teoria jest zawsze warta studiowania, ponieważ pozwala rozmawiać z programistami i rozumieć, jak to działa.

Ale dobrym miejscem do rozpoczęcia rozwoju API jest łączenie się z innymi interfejsami API pierwszy. Poznaj podstawy połączeń po stronie klienta, a stamtąd możesz przejść do tworzenia interfejsu API po stronie serwera, tworząc od podstaw własny interfejs API.

Jeśli taki jest twój cel, weź pod uwagę następujące zasoby, aby pomóc w podróży.

Książki

• Zestaw reguł projektowania interfejsu API REST
• RESTful Web API
• RESTful Web Services Cookbook
• Niezakłócony REST: Przewodnik po projektowaniu Perfect API

Artykuły

• Przewodnik dla początkujących do HTTP i REST
• Tworzenie API RESTful
• Podręcznik nazewnictwa zasobów RESTful
• Tworzenie interfejsu API REST przy użyciu stosu MEAN