0Pricing
AI SaaS Builder · Lekcja

Projektowanie interfejsów RESTful API

Twórz dobrze ustrukturyzowane i wydajne interfejsy API zapewniające płynną komunikację między frontendem a backendem.

Projektowanie interfejsów RESTful API to bezpłatna lekcja AI SaaS Builder na CoddyKit. To lekcja 1 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej AI SaaS Builder, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs AI SaaS Builder zawiera 4 lekcji w sumie.

API: łącze komunikacyjne aplikacji

We współczesnym oprogramowaniu różne części aplikacji często muszą się ze sobą komunikować. Dotyczy to szczególnie AI SaaS, gdzie frontend (czyli to, co widzą użytkownicy) musi współpracować z zaawansowanym backendem AI.

API (Application Programming Interface) można porównać do menu w restauracji. Zawiera ono listę dań (funkcji), które można zamówić, oraz opisuje, jakie składniki (parametry) należy podać i co zostanie zwrócone (wyniki).

W aplikacjach internetowych RESTful APIs są najczęściej stosowanym sposobem komunikacji frontendu z backendem przez internet.

Czym jest REST?

REST to skrót od Representational State Transfer. Jest to styl architektoniczny, a nie protokół, który określa zbiór ograniczeń dotyczących projektowania usług internetowych.

Można go traktować jak plan opisujący, w jaki sposób backend powinien udostępniać swoje usługi innym aplikacjom. Przestrzeganie zasad REST sprawia, że API jest:

  • skalowalne: może obsługiwać większą liczbę żądań,
  • elastyczne: można je łatwo rozwijać i dostosowywać,
  • łatwe w utrzymaniu: jest prostsze do zrozumienia i naprawiania.

Podstawową ideą jest traktowanie wszystkiego jako „zasobu”.

Podstawowe zasady REST

REST opiera się na kilku kluczowych zasadach, które pozwalają osiągnąć te korzyści:

  • Klient–serwer: rozdzielenie odpowiedzialności. Klient obsługuje interfejs użytkownika, a serwer — przechowywanie i przetwarzanie danych.
  • Bezstanowość: każde żądanie klienta do serwera musi zawierać wszystkie informacje potrzebne do jego zrozumienia. Serwer nie przechowuje kontekstu klienta między żądaniami.
  • Możliwość buforowania: odpowiedzi można oznaczyć jako możliwe do zapisania w pamięci podręcznej w celu poprawy wydajności.
  • Jednolity interfejs: jest to najważniejsza zasada z punktu widzenia projektowania. Upraszcza system, zapewniając spójny sposób interakcji z zasobami.

Zasoby: rzeczowniki w API

Zasada „jednolitego interfejsu” oznacza, że API powinno koncentrować się na zasobach. Zasobem może być dowolna nazwana informacja, na przykład użytkownik, produkt lub zamówienie.

Podczas projektowania należy postrzegać zasoby jako rzeczowniki, a nie czasowniki. Punkty końcowe API (adresy URL) powinny odzwierciedlać te rzeczowniki, zazwyczaj w liczbie mnogiej.

  • Zamiast /getUser należy użyć /users
  • Zamiast /createProduct należy użyć /products
  • Zamiast /deleteOrder/123 należy użyć /orders/123

Dzięki temu API jest intuicyjne i spójne.

Metody HTTP: działania

Po zdefiniowaniu zasobów (np. /products) używa się standardowych metod HTTP do wykonywania na nich działań. Metody te pełnią rolę czasowników dla rzeczowników oznaczających zasoby.

  • GET: pobieranie danych (np. GET /products w celu pobrania wszystkich produktów),
  • POST: tworzenie nowych danych (np. POST /products w celu dodania nowego produktu),
  • PUT: aktualizowanie lub zastępowanie istniejących danych (np. PUT /products/123 w celu zaktualizowania produktu 123),
  • DELETE: usuwanie danych (np. DELETE /products/123 w celu usunięcia produktu 123).

Istnieje również metoda PATCH, używana do częściowych aktualizacji, ale te cztery metody są najbardziej podstawowe.

Przykład: pobieranie danych (GET)

Zobaczmy, jak klient może komunikować się z RESTful API w celu pobrania danych za pomocą metody GET.

W tym przykładzie pobieramy konkretny post z publicznego API testowego. Adres URL /posts/1 jednoznacznie identyfikuje zasób.

import requests

# Define the API endpoint for a specific post
url = "https://jsonplaceholder.typicode.com/posts/1"

# Send a GET request
response = requests.get(url)

# Check if the request was successful (status code 200)
if response.status_code == 200:
  print("Successfully retrieved data:")
  print(response.json())
else:
  print(f"Error: {response.status_code} - {response.text}")

Przykład: tworzenie danych (POST)

Aby utworzyć nowy zasób, używamy metody POST. Nowe dane są przesyłane w treści żądania, zazwyczaj w formacie JSON.

Zwróćmy uwagę, że wysyłamy żądanie do punktu końcowego zasobu w liczbie mnogiej (/posts) bez identyfikatora, ponieważ zostanie on nadany przez serwer.

import requests
import json

# Define the API endpoint for creating posts
url = "https://jsonplaceholder.typicode.com/posts"

# Define the data for the new post
new_post_data = {
  "title": "CoddyKit Lesson",
  "body": "This is a new post from CoddyKit!",
  "userId": 1
}

# Send a POST request with the JSON data
response = requests.post(url, json=new_post_data)

# Check if the request was successful (status code 201 Created)
if response.status_code == 201:
  print("Successfully created post:")
  print(response.json())
else:
  print(f"Error: {response.status_code} - {response.text}")

Kody statusu HTTP: informacje zwrotne z API

Po otrzymaniu żądania API odsyła kod statusu HTTP. Ta trzycyfrowa liczba informuje klienta, czy żądanie zakończyło się powodzeniem, czy wystąpił błąd oraz jakiego był rodzaju.

  • 2xx — powodzenie: 200 OK (ogólny sukces), 201 Created (utworzono zasób), 204 No Content (sukces, ale brak danych do zwrócenia).
  • 4xx — błąd klienta: 400 Bad Request (nieprawidłowo sformułowane żądanie), 401 Unauthorized (brak uwierzytelnienia), 403 Forbidden (klient został uwierzytelniony, ale nie ma dostępu), 404 Not Found (zasób nie istnieje).
  • 5xx — błąd serwera: 500 Internal Server Error (wystąpił problem po stronie serwera).

Stosowanie odpowiednich kodów statusu ma kluczowe znaczenie dla dobrze zaprojektowanego API.

Format danych: JSON dla prostoty

Podczas wysyłania danych do RESTful API i odbierania ich z niego często stosuje się format JSON (JavaScript Object Notation).

JSON jest lekki, czytelny dla człowieka i łatwo analizowany przez większość języków programowania. Reprezentuje dane jako pary klucz–wartość oraz tablice, dzięki czemu doskonale nadaje się do uporządkowanych informacji.

Choć XML był kiedyś popularny, JSON stał się de facto standardem dla webowych API ze względu na prostotę i wydajność.

Wersjonowanie API

W miarę rozwoju AI SaaS będzie rozwijać się również API. Można dodawać nowe funkcje, zmieniać struktury danych, a nawet usuwać stare punkty końcowe. Właśnie temu służy wersjonowanie API.

Wersjonowanie pozwala wprowadzać zmiany bez zakłócania działania istniejących aplikacji korzystających z API. Często stosuje się umieszczanie numeru wersji w adresie URL:

  • /v1/users (wersja 1),
  • /v2/users (wersja 2).

Zapewnia to zgodność wsteczną i płynniejsze przejście dla użytkowników.

Sprawdź swoje umiejętności projektowania API

​​Które z poniższych zasad są podstawowymi zasadami projektowania RESTful API?

Podsumowanie: projektowanie solidnych API

Gratulacje! Poznali Państwo podstawy projektowania RESTful API.

  • API umożliwiają komunikację między frontendem a backendem.
  • REST to styl architektoniczny kładący nacisk na zasoby i standardowe metody HTTP.
  • Zasoby powinny być identyfikowane w adresach URL za pomocą rzeczowników w liczbie mnogiej.
  • Metody HTTP (GET, POST, PUT, DELETE) określają działania wykonywane na tych zasobach.
  • Kody statusu HTTP dostarczają kluczowych informacji o wyniku żądania.
  • JSON jest preferowanym formatem danych do komunikacji z API.
  • Wersjonowanie API zapewnia płynny rozwój i zgodność wsteczną.

Opanowanie tych pojęć ma kluczowe znaczenie dla tworzenia skalowalnych i łatwych w utrzymaniu backendów AI SaaS.

Często zadawane pytania

Czy lekcja „Projektowanie interfejsów RESTful API” jest bezpłatna?

Tak — pełny tekst „Projektowanie interfejsów RESTful API” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu AI SaaS Builder, przejdź na CoddyKit PRO. Kurs AI SaaS Builder zawiera 4 lekcji w sumie.

Co nauczysz się w „Projektowanie interfejsów RESTful API”?

Twórz dobrze ustrukturyzowane i wydajne interfejsy API zapewniające płynną komunikację między frontendem a backendem. Ćwiczysz AI SaaS Builder z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć AI SaaS Builder?

Nie wymagamy żadnego doświadczenia. AI SaaS Builder w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 1 z 4.

Ile czasu zajmuje lekcja „Projektowanie interfejsów RESTful API”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji AI SaaS Builder?

Tak. Każda lekcja AI SaaS Builder zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Projektowanie interfejsów RESTful API
  2. Zarządzanie bazami danych na potrzeby SaaS
  3. Uwierzytelnianie i autoryzacja użytkowników
  4. Ograniczanie liczby żądań i kolejkowanie żądań AI
← Powrót do AI SaaS Builder