Tillbaka till bloggen
Bygg din första SwiftUI-app (del 4): Konfigurera en simulerad server med Postman
I föregående artikel designade vi en inloggningsskärm som gör en API-förfrågan. Vi har dock ingen server som hanterar denna förfrågan ännu. API-anrop är en viktig del av varje mobilapp som kommunicerar med en fjärrdatabas, vilket är de flesta appar idag, så det säger sig självt att vi måste lägga till den här funktionen i vår SwiftUI-app.
För att göra detta måste vi naturligtvis använda ett API. Ett sätt att göra detta är att ansluta till ett av de offentligt tillgängliga API:erna , vilket är fullt möjligt för elever. Att använda dessa API:er har dock vissa nackdelar:
Av alla dessa anledningar kommer vi inte att använda ett publikt API. Istället kommer vi att skapa vårt eget! Men inga problem, du kommer inte att behöva konfigurera en Node.js-server på din maskin! 😅
Vi kommer att göra något mycket enklare istället. Vi ska sätta upp en simulerad server i Postman! På så sätt kan vi exakt definiera vad våra förfrågningar kommer att vara och hårdkoda svaren så att förfrågningarna returnerar exakt vad vi vill att de ska. Naturligtvis kommer vi att hårdkoda all serverdata, och det kommer inte att finnas mycket "riktig" logik, men i gengäld får vi en utmärkt uppsättning simulerade förfrågningar och svar att använda i vår app.
Öppna Postman och klicka på knappen Mock Servers till vänster i din arbetsyta.
Klicka sedan på knappen Skapa simulerad server för att starta processen att skapa servern. Lämna fliken samling på Skapa en ny samling och ändra den första Request Method till POST . Vår första begäran blir att logga in, så låt oss bara ange login i fältet Request URL . Vi behöver inte göra något mer i det här steget, så låt oss fortsätta genom att klicka på Nästa .
På nästa skärm anger du namnet på Mock-servern (i mitt fall heter den SwiftUI Mock Server ) och markerar kryssrutan Simulera fast nätverksfördröjning för att göra vår server lite mer realistisk. Lämna allt annat som det är och klicka på knappen Skapa Mock Server .
Vi har precis skapat vår helt nya mock-server! Nu ska vi kolla fliken Samlingar, för en samling borde ha skapats där.
VIKTIGT: När du skapar mockservern skapas automatiskt en miljö för den. Miljön kommer att namnges med samma namn som mockservern, så i mitt fall kallas den SwiftUI Mock Server. Denna miljö kommer att lagra den fula bas-URL:en (URL:en kommer att se ut ungefär så här: https://72a29288-615d-4ed4-8f9a-21b224056d7f.mock.pstmn.io ) i url- variabeln. Så, för att faktiskt kunna använda din nya mockserver, se till att välja rätt miljö i det övre högra hörnet!
Nu kavlar vi upp ärmarna, för det är dags att skapa några mock requests. I Postman kallas dessa mock requests för Examples . Om du vill lära dig hur allt detta fungerar i detalj finns det inget bättre ställe att leta på än i Postman-dokumentationen , eftersom den är full av exempel och skärmdumpar. Men här ska vi bara göra en snabb snabbkurs.
Innan vi börjar kan du ta bort standardexemplet under vår inloggningsförfrågan , så att vi har en nystart.
Nu ska vi skapa en simulerad förfrågan och ett svar för vårt lyckade fall. Klicka på de tre punkterna till höger om vår inloggningsförfrågan och välj Lägg till exempel .
Låt oss döpa detta exempel till Framgång, eftersom det simulerar ett lyckat inloggningsfall.
Växla sedan till fliken Rubriker och lägg till en rubrik Innehållstypmed värdet applikation/json. Glöm inte detta steg, annars fungerar inte övningsexemplen korrekt!
Växla nu till fliken Brödtext, byt typ från Text till JSON i väljaren och ange nyttolasten för förfrågningstexten som du vill ska resultera i ett lyckat svar. Nyttelasten måste innehålla en användarnamn och en lösenordDu kan använda vilka värden du vill, men om du vill följa artikeln kan du använda det här exemplet:
{
"username": "johndoe",
"password": "grayfox123"
}
Vi är klara med vår begäran! Nu ska vi definiera vårt svar. Först, eftersom detta svar indikerar framgång, kommer vi att ange 200 i Statuskod fält.
Låt oss nu lägga till denna nyttolast i svarstexten :
{
"success": true,
"data": {
"accessToken": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjMxMjViZmJkZWFkMTVmN2NkMmRlZGE4NmFkNjk3NjkxIn0.eyJpYXQiOjE2NTAwMzUzMzIsImV4cCI6MTY1MDAzODkzMiwiaWQiOjEsIm5hbWUiOiJKb2huIERvZSJ9.vLvd8ecviYJj6dpPi8gqkb8WZCV4TVHIffmVOG08-EwMZbSfqD7iMrwg1eqiHr_weidhb4ZR1JlzEvNfaHbSHKBD6YIVjg_vFDAksEwKChhpccvIyXa-D4Nx-kSHGg4zOL4JP7HQbdQoiQqn2dahDBJ8lqkGHMaTFED54tg5hx_Ziwm_ozkvQ4ycHDlLFRej_jbIxl0Fyscwe6u3RGQyQpjP5BNJJP6s8K9iCpM1Q6RzC3rXWZP6fBAM9_HVTbgOa3Mtmou5RpvCBiosHffD1DRsdq1Tg2K7dyxq49Zx_DcrHyoeSyWX-45ErLGzODe2bWlCpWD89_pn2pMGOW6y_Bw1p-0PAOPyG0my5lar9dhIfyGRBD2jJ4ThpAQKeO3ixzOa_PRGBvWAjp1LPnMEbe2YI9IzMgbY-EKrqrEGtD0UgHXys7SUn-ltA1FSCvmfnMbpPgKiKVWEEpir3WfZyo3B5A4zpPeoayeHJCcHD1elsTvVkpjGrj-nunTYGz46",
"refreshToken": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjMxMjViZmJkZWFkMTVmN2NkMmRlZGE4NmFkNjk3NjkxIn0.eyJpYXQiOjE2NTAwMzUzMzIsImV4cCI6MTY1MjYyNzMzMiwiaWQiOjEsIm5hbWUiOiJKb2huIERvZSJ9.HoXcIgllq6eBECDZGM4fIOxHR7dx8E5K255qKLsa2HG3a0Kfe8QZmQBGpRpxUl0h81Y42Xh0iMj4u1HO7tdSUiHFds_Sot2SKrZLmu1cZc9yz59Euu4qbJn0w5tosb4jKi67WgDjRYxNx8fBrdaO7c4Zu84u2rZJJNHeljKhaMpvTXEbeG9IkILEFR81P0XaWklALgt9r-lcUhiHcyCsgOdwp2asnB9UQIYC3sTeC2gIUHYRgeYuzrkvm0KU05iizNvZSGyLEtXBZpE7b2a9TjAXZmIMrSA19mlCBX_EZGBzjANWw6yg4c6yJW2kwfli-FpAbbfZVebskRNd8ftvzkBzSh8wDvA25mDZlexm-zIspoBwOgyPPxZ7wHQ7i3g3lAk0PdMEJBYsES3rYrNtmkxwY5ovtGbMOVYXfWpx_xrM5eCiR1wvY1-DBSud0M-LeUvgEpRQ0rhH8zirL02DrvAChk3IX9EEvXOLH6xn-2bhrdahEO7ZHYe2RZK9vPxZ"
},
"error": null
}För att vara tydlig, vårt lyckade svar kommer att returnera två JWT-tokens som används i Bearer-auktoriseringen: en åtkomsttoken och en uppdateringstoken . När du har loggat in kommer du att använda dessa tokens för att auktorisera alla dina API-förfrågningar.
Om du är nyfiken på hur de skapas, så genererade jag dem just med hjälp av det här praktiska online-verktyget JWT Generator . I ett verkligt scenario kommer de dock att skapas och signeras av din backend. Och om du är ännu mer nyfiken och vill ta reda på vilken information dessa tokens innehåller, klistra bara in dem i jwt.io och se!
Så här ska allting se ut i slutändan, i Postman:
Vårt framgångsfall är officiellt avklarat! 🎉
Glöm inte att klicka på Spara-knappen i det övre högra hörnet!
Nu ska vi skapa vårt felexempel. Det kommer att återspegla fallet när en användare anger ett ogiltigt användarnamn och lösenord. Vi skapar det på samma sätt som vi gjorde tidigare. Låt oss namnge vårt nya exempel Ogiltiga inloggningsuppgifter, och lägg till rubriken Innehållstyp med värdet applikation/json som vanligt.
Nyttelasten blir dock i detta fall:
{
"username": "johndoe",
"password": "bluedog123"
}Nu till svaret. Detta är ett felsvar, så låt oss sätta 400 i Statuskod fält.
Vi vill få ett felmeddelande som talar om att just den här användarnamn- och lösenordskombinationen är fel. Låt oss därför lägga in följande JSON i svaret:
{
"success": false,
"data": null,
"error": {
"key": "Login.InvalidCredentials",
"message": "Invalid username and password combination."
}
}Detta är slutresultatet:
Det avslutar vårt misslyckandeexempel! Dags att testa 🤩
För att testa dessa två exempel, klicka på inloggningsförfrågan i den vänstra rutan, som finns ovanför våra två nyskapade exempel.
VIKTIG: Eftersom vi matchar våra exempel baserat på begäran, du måste inkludera en särskild rubrik x-mock-match-request-body med värdet sann i var och en av dina önskemål.
Om du glömmer den här rubriken kommer du att uppleva några väldigt konstiga beteenden när du kör dina mock-exempel! Mer information om begärda rubriker finns på den här länken .
Nu ska vi ange vår begäran om framgång och trycka på Skicka .
Voilà! Vi fick precis vad vi förväntade oss i svar! 😆
Nu ska vi ändra lösenordet till det "felaktiga" och trycka på Skicka igen.
Begäran misslyckades som förväntat, och vi fick exakt det felsvar som vi definierade tidigare! Så även om inloggningsåtgärden misslyckades är det en stor framgång för oss! 😊
Tänk på att om du kör en förfrågan som inte matchar något av dina förberedda exempel får du felmeddelandet "Inga matchande förfrågningar". Så se till att täcka alla fall du vill testa med lämpliga exempel!
Nu när vi har våra exempel på API-förfrågningar för framgång och misslyckanden igång, låt oss uppdatera vår iOS-appkod så att den kan testa dessa förfrågningar.
Först måste vi ställa in rätt bas-URL. Om du minns, tidigare hårdkodade vi den till en dummy-platshållare. bas_urlNu när vi har en mock-server behöver vi ange dess bas-URL istället. För att ta reda på bas-URL:en för din mock-server klickar du på ögonikonen "Snabbtitt på miljön" i det övre högra hörnet.
Kopiera sedan webbadressen som är lagrad i Nuvarande värde fält (utan https:// del). Din bas-URL kommer att skilja sig från den som visas på den här skärmdumpen.
Nu ska vi öppna vår LoginAction -fil.
import Foundation
struct LoginAction {
var parameters: LoginRequest
func call(completion: @escaping (LoginResponse) -> Void) {
let scheme: String = "https"
let host: String = "72a29288-615d-4ed4-8f9a-21b224056d7f.mock.pstmn.io" // Put your mock server url here
let path = "/login"
var components = URLComponents()
components.scheme = scheme
components.host = host
components.path = path
guard let url = components.url else {
return
}
var request = URLRequest(url: url)
request.httpMethod = "post"
request.addValue("application/json", forHTTPHeaderField: "Content-Type")
request.addValue("application/json", forHTTPHeaderField: "Accept")
request.addValue("true", forHTTPHeaderField: "x-mock-match-request-body") // Add this request header
. . .Vi behöver bara uppdatera två saker i den här filen. Först, ersätt den gamla bas_url värdet av ditt värd variabel med den mock-server-URL som du kopierade från Postman.
För det andra, lägg till en x-mock-match-request-body begäranhuvud med värdet sann, precis som vi gjorde i Postman tidigare. Observera att när du växlar från mock-servern till en riktig backend kan du ta bort den här headern.
Nu ska vi logga inloggningssvaret i vår vymodell så att vi vet att inloggningsförfrågan har slutförts. Om allt går som planerat bör vi se vår åtkomsttoken i konsolen.
import Foundation
class LoginViewModel: ObservableObject {
@Published var username: String = ""
@Published var password: String = ""
func login() {
LoginAction(
parameters: LoginRequest(
username: username,
password: password
)
).call { response in
// Login successful, navigate to the Home screen
print("Access token", response.data.accessToken)
}
}
}Vi kommer att testa vårt inloggningsflöde med den kombination av lyckade inloggningsuppgifter som vi definierade i vårt mock-exempel för lyckade resultat.
{
"username": "johndoe",
"password": "grayfox123"
}Nu kör vi appen och testar den!
Lyckades! Vår simulerade server tog emot API-förfrågan och returnerade det förväntade svaret. Precis som planerat. 😏
Nu vet vi hur man simulerar API-förfrågningar, vilket är en otroligt användbar färdighet att ha. Med denna kunskap kan du definiera dina egna svar när du inte har ett produktions-API klart. Detta kan hjälpa dig att utveckla din app mycket snabbare och täcka din app med alla möjliga typer av tester utan att behöva vänta på att backend-systemet ska vara klart och driftsatt.
I fortsättningen av den här serien kommer vår SwiftUI-app att anropa de två förfrågningar vi just skapade, och den kommer att få samma JSON-svar som vi gjorde här i Postman.
Bra jobbat med dina framsteg hittills, och vi ses i nästa artikel! 😉
Om du vill ladda ner ett projekt som innehåller allt vi har gjort hittills kan du göra det genom att klicka här .
” Bygg din första SwiftUI-app ” är en del av en artikelserie som är utformad för att hjälpa dig att komma igång med iOS-apputveckling.
Om du har några frågor kring någon av ovanstående tankar, dela dem gärna i kommentarsfältet.
Klicka här för att läsa del 1: Projektuppbyggnad
Klicka här för att läsa del 2: Projektarkitektur
Klicka här för att läsa del 3: Skapa inloggningsskärmen
Vi har möjliggjort kommunikation med API:et genom att skapa en simulerad server med en inloggning/ exempel på begäran. Men för närvarande skriver vi bara ut åtkomsttoken till konsolen.
Vi vill navigera till appens huvudskärm efter en lyckad inloggning och även förbli inloggade nästa gång vi kör appen. Vi kommer att lära oss hur man hanterar auktorisering och gör allt detta i nästa artikel!