Web applications
Tasks studies - laboratory
Project maintained by dawidolko
Hosted on GitHub Pages — Theme by dawidolko
Zadanie 10.13: * Przed następnymi zajęciami zapoznać się z następującymi zagadnieniami:
• REST (Representational state transfer),
• REST API (RESTful API),
• 6 zasad REST API (w tym wyjaśnić dokładnie zasadę bezstanowości),
• endpoint’y,
• zasoby (resources),
• operacje CRUD na zasobach,
• zagadnienie modelu dojrzałości API Richardsona, omówić poziomy,
• metody HTTP używane na 2 poziomie dojrzałości,
• kody HTTP (nazwa angielska, tłumaczenie, najczęstsze zastosowanie):
200, 201, 204, 400, 401, 403, 404, 405, 422, 500,
• ocenić poziom dojrzałości API GitHub’a,
• wersjonowanie API,
• czy API GitHub’a jest wersjonowane?
1. REST (Representational State Transfer)
REST to styl architektoniczny dla systemów rozproszonych, którego głównymi cechami są:
- Bezstanowość,
- Jednolity interfejs,
- Możliwość buforowania odpowiedzi.
2. REST API (RESTful API)
RESTful API to API, które przestrzega zasad REST, umożliwiając komunikację między klientem a serwerem za pomocą protokołu HTTP, wykorzystując standardowe metody takie jak GET, POST, PUT, DELETE.
3. 6 zasad REST API
- Klient-serwer: oddzielenie odpowiedzialności między interfejsem użytkownika a przechowywaniem danych, co zwiększa portowalność interfejsu użytkownika na różne platformy.
- Bezstanowość: każde żądanie od klienta do serwera musi zawierać wszystkie informacje niezbędne do jego zrozumienia i wykonania.
- Cache’owalność: odpowiedzi muszą być definiowalne jako cache’owalne lub nie-cache’owalne.
- Jednolity interfejs: zasady dotyczące identyfikowania zasobów, reprezentacji zasobów, samoobsługowych wiadomości i hipermediów jako silnika stanu aplikacji.
- Warstwowość systemu: klient nie może widzieć poza swoją warstwę bezpośrednich połączeń.
- Kod na żądanie (opcjonalnie): serwery mogą czasowo rozszerzać lub dostosowywać funkcjonalność klienta przez przesyłanie mu kodu wykonywalnego.
4. Zasady bezstanowości
Bezstanowość oznacza, że każde żądanie HTTP od klienta do serwera musi zawierać wszystkie informacje potrzebne serwerowi do zrozumienia żądania, niezależnie od jakichkolwiek wcześniejszych żądań. Nie ma przechowywania kontekstu między żądaniami.
5. Endpointy
Endpoint w REST API to konkretny URL, pod którym można uzyskać dostęp do określonego zasobu lub zasobów.
6. Zasoby (resources)
Zasób to obiekt lub reprezentacja jakiegoś elementu systemu, do którego można uzyskać dostęp za pomocą unikalnego URI.
7. Operacje CRUD na zasobach
CRUD to akronim od Create, Read, Update, Delete — podstawowe operacje, które można wykonywać na zasobach w systemie.
8. Model dojrzałości API Richardsona
Model dojrzałości Richardsona sklasyfikuje REST API według trzech poziomów:
- Poziom 0: Jedno URI, jeden sposób interakcji (HTTP POST).
- Poziom 1: Indywidualne URI dla poszczególnych zasobów.
- Poziom 2: Poszczególne URI z odpowiednimi metodami HTTP.
- Poziom 3: HATEOAS (Hypermedia As The Engine Of Application State), gdzie odpowiedź zawiera dynamicznie generowane linki do innych zasobów.
9. Metody HTTP na 2 poziomie dojrzałości
Na drugim poziomie modelu Richardsona używane są metody HTTP takie jak GET, POST, PUT, PATCH, DELETE, które odpowiadają operacjom CRUD.
10. Kody HTTP
- 200 OK: Żądanie zakończone sukcesem.
- 201 Created: Pomyślnie utworzono nowy zasób.
- **
204 No Content**: Żądanie zakończone sukcesem, ale brak zawartości do przesłania w odpowiedzi.
- 400 Bad Request: Nieprawidłowe żądanie ze strony klienta.
- 401 Unauthorized: Żądanie wymaga uwierzytelnienia.
- 403 Forbidden: Serwer odmawia odpowiedzi na żądanie.
- 404 Not Found: Nie znaleziono zasobu pasującego do żądania.
- 405 Method Not Allowed: Metoda nie jest dozwolona dla danego zasobu.
- 422 Unprocessable Entity: Nie można przetworzyć żądania z powodu błędów semantycznych.
- 500 Internal Server Error: Błąd serwera niepozwalający na przetworzenie żądania.
11. Poziom dojrzałości API GitHub’a
GitHub API to REST API, które osiąga 3 poziom w modelu dojrzałości Richardsona, ponieważ implementuje HATEOAS.
12. Wersjonowanie API
Wersjonowanie API pozwala na zarządzanie zmianami i zapewnienie kompatybilności wstecz. GitHub używa wersjonowania w swoim API.
13. Czy API GitHub’a jest wersjonowane?
Tak, API GitHuba jest wersjonowane. Aktualna wersja jest zazwyczaj dostępna w nagłówkach żądania jako domyślna, ale można określić konkretną wersję w nagłówku Accept podczas wykonywania żądania.