zastanawiałeś się kiedyś, jaka jest różnica między GET I POSTżądaniami, lub kiedy użyć PUT? Nie jesteś sam. Mając podstawowe zrozumienie różnych metod HTTP lub czasowników, API supports jest pomocną wiedzą podczas eksploracji i testowania API.
w tym poście omówię, w jaki sposób każda metoda HTTP jest używana i jak ją wykorzystać w testowaniu API.
metody HTTP
GETPOSTPUTHEADDELETEPATCHOPTIONS
Pobierz
GET żądania są najczęściej i powszechnie stosowane metody w API i stron internetowych. Mówiąc najprościej, metoda GET służy do odzyskiwania danych z serwera w określonym zasobie. Na przykład, załóżmy, że masz APIwith/users endpoint. Składanie żądania GET do tego punktu końcowegopowróć listę wszystkich dostępnych użytkowników.
ponieważ żądanie GET jest tylko żądaniem danych i nie modyfikuje żadnych źródeł, uważa się, że jest to bezpieczna i idempotentna metoda.
testowanie API za pomocą żądań GET
podczas tworzenia testów dla API metodaGET będzie prawdopodobnie najczęstszym rodzajem żądania składanego przez konsumentów Usługi, dlatego ważne jest, aby sprawdzić każdy znany punkt końcowy za pomocą żądania GET.
na poziomie podstawowym, te rzeczy powinny zostać zatwierdzone:
- sprawdź, czy poprawne żądanie GET zwraca kod statusu
200. - upewnij się, że żądanie GET do określonego zasobu zwraca correctdata. Na przykład
GET /userszwraca listę użytkowników.
GET jest często domyślną metodą w klientach HTTP, więc tworzenie testów dla tych zasobów powinno być proste za pomocą dowolnego wybranego narzędzia.
POST
w usługach internetowychPOST żądania są używane do wysyłania danych do serwera APIserver w celu utworzenia lub udpate zasobu. Dane wysyłane do serwera są zapisywane w treści żądania HTTP.
najprostszym przykładem jest formularz kontaktowy na stronie internetowej. Po wypełnieniu danych wejściowych w formularzu i naciśnięciu Wyślij, dane te są umieszczane w treści odpowiedzi żądania i wysyłane do serwera. To może JSON, XML, lub parametry zapytania (jest wiele innych formatów,ale są to najczęstsze).
warto zauważyć, że zapytanie POST nie jest idempotentne. W przeciwieństwie do żądania GET, które nie zmienia danych. Oto świetne Wyjaśnienie idempotentności.
testowanie API z żądaniami POST
druga najczęściej spotykana metoda HTTP, którą napotkasz w testach API POST. Jak wspomniano powyżej, POST żądania są używane do wysyłania danych do serwera API i tworzenia lub aktualizacji zasobu. Ponieważ żądania POST modyfikują dane, ważne jest, aby testy API dla wszystkich metod POST.
oto kilka wskazówek dotyczących testowania żądań postów:
- Utwórz zasób z żądaniem
POSTI upewnij się, że zwracany jest kod statusu200. - następnie wykonaj
GETżądanie dla tego zasobu i upewnij się, że dane zostały poprawnie zapisane. - Dodaj testy, które zapewniają, że
POSTżądania nie powiodą się z nieprawidłowymi lub źle sformatowanymi danymi.
aby uzyskać więcej pomysłów na wspólne testy API, sprawdź ten post.
PUT
Simlar to POST, PUT żądania są używane do wysyłania danych do API toupdate lub tworzenia zasobu. Różnica polega na tym, że żądania danych są idempotentne. To, że wielokrotne wywołanie tego samego żądania PUT zawsze przyniesie ten sam rezultat. W przeciwieństwie do tego, wielokrotne wywoływanie żądania POST powodująmają skutki uboczne wielokrotnego tworzenia tego samego zasobu.
ogólnie, gdy żądaniePUT utworzy zasób, serwer odpowie za pomocą201Created), a jeśli żądanie zmieni istniejący zasób, serwer zwróci200OK) lub204NoContent).
testowanie API za pomocą żądań PUT
testowanie APIPUT jest bardzo podobne do testowania Postrequestów. Ale teraz, gdy znamy różnicę między nimi (idempotency), możemy utworzyć testy API, aby potwierdzić to zachowanie.
Sprawdź te rzeczy podczas testowania wysłanych żądań:
- wielokrotne wywołanie
PUTżądanie zawsze zwraca ten sam wynik(idempotent). - właściwy kod stanu jest zwracany podczas tworzenia i aktualizacji zasobu (np.
201lub200204). - Po zaktualizowaniu zasobu o
PUTżądanie, aGETżądanie dla zasobu powinno zwrócić poprawne dane. -
PUTżądania powinny się nie udać, jeśli w formularzu podano nieprawidłowe dane — nic nie powinno być aktualizowane.
PATCH
aPATCH żądanie jest jedną z mniej znanych metod HTTP, ale nie umieszczam go tak wysoko na liście, ponieważ jest podobny do POST andPUT. Różnica w przypadku PATCH polega na tym, że do zasobu stosuje się tylko częściowe modyfikacje.
różnica między PATCH I PUT polega na tym, że żądanie Patch nie jest idempotentne (jak żądanie POST).
aby rozwinąć częściową modyfikację, powiedzmy, że Twoje API ma/users/{{userid}} punkt końcowy, a użytkownik ma nazwę użytkownika. W przypadku żądania aPATCH może być konieczne tylko wysłanie zaktualizowanej nazwy użytkownika w treści żądania – w przeciwieństwie do POST I PUT, które wymagają podmiotu fulluser.
testowanie API z żądaniami łatek
ponieważ metoda PATCH jest tak prosta do publikowania i umieszczania, stosuje się wiele tych samych technik testowania. Nadal ważne jest, aby zweryfikować zachowanie wszystkich punktów końcowych API, które akceptują tę metodę.
na co zwrócić uwagę podczas testowania żądań poprawek:
- pomyślne
PATCHżądanie powinno zwrócić2xxkod statusu. -
PATCHżądania powinny się nie udać, jeśli w zapytaniu podano nieprawidłowe dane — nic nie powinno być aktualizowane.
semantyka żądań poprawek w dużej mierze zależy od konkretnego testowanego interfejsu API.
Usuń
metoda DELETE jest dokładnie taka, jak brzmi: Usuń zasób pod określonym adresem URL. Ta metoda jest jedną z bardziej powszechnych w RESTfulAPIs, więc dobrze jest wiedzieć, jak to działa.
testowanie API z żądaniami DELETE
DELETE żądania powinny być mocno Przetestowane, ponieważ zazwyczaj usuwają dane z bazy danych. Zachowaj ostrożność podczas testowania metod usuwania, upewnij się, że używasz poprawnych poświadczeń i nie testujesz z danymi realuser.
typowy przypadek testowy dla żądania usunięcia wyglądałby tak:
- Utwórz nowego Użytkownika z
POSTżądanie do/users - z identyfikatorem użytkownika zwróconym z
POST, UtwórzDELETEzapytanie do/users/{{userid}} - kolejne
GETzapytanie do/users/{{userid}}powinno zwrócić kod statusu nie znaleziono 404.
ponadto wysłanie żądania usunięcia do nieznanego zasobu powinno zawierać kod stanu inny niż 200.
HEAD
metodaHEAD jest prawie identyczna zGET, z wyjątkiem braku ciała odpowiedzi. Innymi słowy, jeśli GET /users zwróci listę Użytkowników, to HEAD /users wykona to samo żądanie, ale nie zwróci listy użytkowników.
Head requests są przydatne do sprawdzania, co żądanie GET zostanie zwrócone przed wykonaniem żądania GET-na przykład przed załadowaniem dużego pliku lub responsebody. Dowiedz się więcej o żądaniach głowy w MDN.
warto zaznaczyć, że nie każdy punkt końcowy obsługujący GETwill obsługuje HEAD-to całkowicie zależy od testowanego API.
testowanie API za pomocą żądań HEAD
Wykonywanie żądań API za pomocą HEAD metod jest w rzeczywistości skutecznym sposobem sprawdzenia, czy zasób jest dostępny. Dobrze jest mieć test dla żądań HEAD wszędzie tam, gdzie masz test dla żądań GET (o ile API go obsługuje).
Sprawdź te rzeczy podczas testowania API z żądaniami HEAD:
- Verify andcheckHTTP headers returnedfrom a head request
- dokonaj asercji przeciwko kodowi stanu żądań HEAD
- żądania testowe z różnymi parametrami zapytańr, aby zapewnić APIresponds
kolejny użyteczny przypadek dlaHEAD żądańsisapi smoke testing-wykonaj żądanie HEAD dla każdego punktu końcowego API, aby upewnić się, że są jest dostępny.
opcje
wreszcie mamyOPTIONS żądania. Żądania opcji są jednym z moich ulubionych, choć nie tak szeroko stosowane jak inne metody HTTPmethods. W skrócie, żądanie opcji powinno zwracać dane opisujące, jakie inne metody i operacje serwer obsługuje podanym adresem URL.
żądania opcji są bardziej luźno zdefiniowane i używane niż pozostałe,co czyni je dobrym kandydatem do testowania krytycznych błędów API. Jeśli anAPI nie oczekuje żądania opcji, dobrze jest umieścić kazeinę testową, która weryfikuje niewłaściwe zachowanie.
testowanie API z żądaniami opcji
testowanieOPTIONS żądanie zależy od usługi sieciowej; czy nie wspiera tego i to, co ma powrócić, Będzie definiowało, jak powinieneś to przetestować.
jak zweryfikować punkt końcowy za pomocą opcji:
- przede wszystkim sprawdź nagłówki odpowiedzi i kod stanu żądania
- Testuj punkty końcowe, które nie obsługują opcji, i upewnij się, że zawodzą odpowiednio
więcej zasobów
to, co omówiłem powyżej, jest tylko punktem wyjścia do odkopywania metod toHTTP i testowania różnych zasobów API. Zakłada również, że w większości przypadków jest idealny – w świecie rzeczywistym API nie są tak skonstruowane, jak przykłady powyżej. To sprawia, że testowanie różnych metod przeciwko Apian skutecznym sposobem na znalezienie nieoczekiwanych błędów.