Als REST-applicaties stateloos zouden moeten zijn, hoe beheer je dan sessies?

Ik heb wat opheldering nodig. Ik heb gelezen over REST en het bouwen van RESTful-applicaties. Volgens wikipedia is REST zelf gedefinieerd als Representational State Transfer. Ik begrijp daarom al die staatloze gobbledeygookdie iedereen blijft uitspugen niet.

Van wikipedia:

Op een bepaald moment kan een klant in de overgang zijn tussen:
applicatiestatussen of “in rust”. Een cliënt in rusttoestand is in staat om:
interactie met de gebruiker, maar creëert geen belasting en verbruikt geen per-client
opslag op de set servers of op het netwerk.

Zeggen ze alleen dat je geen gegevensopslag op sessie-/applicatieniveau gebruikt???

Ik begrijp dat een van de doelen van REST is om URI-toegang consistent en beschikbaar te maken, bijvoorbeeld in plaats van paging-verzoeken in berichten te verbergen, waardoor het paginanummer van een verzoek een onderdeel wordt van de GET-URI. Lijkt me logisch. Maar het lijkt erop dat het gewoon overboord gaat door te zeggen dat geen gegevens per cliënt(sessiegegevens) ooit aan de serverzijde mogen worden opgeslagen.

Wat als ik een wachtrij met berichten had, en mijn gebruiker wilde de berichten lezen, maar terwijl hij ze las, bepaalde berichten van afzenders wilde blokkeren voor de duur van zijn sessie? Zou het niet logisch zijn om dit op een plaats aan de serverkant op te slaan en de server alleen berichten (of bericht-ID’s) te laten verzenden die niet door de gebruiker zijn geblokkeerd?

Moet ik echt de hele lijst met afzenders van berichten verzenden om te blokkeren telkens wanneer ik de nieuwe berichtenlijst opvraag? De berichtenlijst die voor mij relevant is, zou in de eerste plaats niet eens een openbaar beschikbare bron zijn..

Nogmaals, ik probeer dit gewoon te begrijpen. Iemand alsjeblieftverduidelijking.

Bijwerken:

Ik heb een stack-overflow-vraag gevonden met een antwoord dat me niet helemaal daarheen brengt:
Status beheren in REST
die zegt dat de client-status die belangrijk is moetenallemaal worden overgedragen bij elk verzoek…. Ugg.. lijkt veel overhead… Klopt dit??

Antwoord 1, autoriteit 100%

De fundamentele verklaring is:

Geen clientsessiestatus op de server.

Met stateless betekent dit dat de servergeen enkele status opslaat over de clientsessieaan de serverzijde.

De clientsessiewordt op de client opgeslagen. De server is stateless, wat betekent dat elke server elke client op elk moment kan bedienen, er is geen sessie-affiniteitof sticky-sessies. De relevante sessie-informatie wordt opgeslagen op de client en indien nodig doorgegeven aan de server.

Dat sluit niet uit dat andere services waarmee de webserver praat, status behouden over bedrijfsobjecten zoals winkelwagentjes, alleen niet over de huidige applicatie-/sessiestatus van de klant.

De applicatiestatus van de clientmag nooit op de server worden opgeslagen, maar moet worden doorgegeven van de clientnaar elke plaats waar deze nodig is.

Dat is waar de STin RESTvandaan komt, Statusoverdracht. U draagt ​​de status over in plaats van dat de server deze opslaat. Dit is de enige manier om op te schalen naar miljoenen gelijktijdige gebruikers.Al is het maar omdat miljoenen sessies miljoenen sessies zijn.

De belasting van sessiebeheer wordt afgeschreven over alle clients, de clients slaan hun sessiestatus op en de servers kunnen vele ordes van grootte of meer clients op een stateloze manier bedienen.

Zelfs voor een service waarvan u denkt dat deze slechtsnodig zal zijn in de tienduizenden gelijktijdige gebruikers, moet u uw service nog steeds stateloos maken. Tienduizenden zijn nog steeds tienduizenden en er zullen tijd- en ruimtekosten aan verbonden zijn.

Statloos is hoe het HTTP-protocol en het web in het algemeen zijn ontworpen om te werken en het is een over het algemeen eenvoudiger implementatie en je hebt een enkel codepad in plaats van een heleboel logica aan de serverzijde om een ​​heleboel sessiestatus te behouden.

>

Er zijn enkele zeer basale implementatieprincipes:

Dit zijn principes, geen implementaties, hoe u aan deze principes voldoet, kan verschillen.

Samengevat zijn de vijf belangrijkste principes:

1. Geef elk “ding” een ID
2. Koppel dingen aan elkaar
3. Gebruik standaardmethoden
4. Bronnen met meerdere representaties
5. Statloos communiceren

Er staat niets over authenticatie of autorisatie in de REST dissertatie.

Omdat er niets anders is dan het authenticeren van een verzoek dat REST is, van een verzoek dat dat niet is. Authenticatie is niet relevant voor de RESTful-discussie.

Uitleggen hoe u een staatloze toepassing kunt maken voor uw specifieke vereisten, is te breedvoor StackOverflow.

Het implementeren van authenticatie en autorisatie met betrekking tot REST is zelfs nog meer te breeden verschillende benaderingen van implementaties worden in het algemeen uitgebreid uitgelegd op internet.

Opmerkingen waarin om hulp/info wordt gevraagd, zullen/moeten worden gemarkeerd als
Niet langer nodig.

Antwoord 2, autoriteit 74%

Statloosheid betekent dat elk HTTP-verzoek volledig geïsoleerd plaatsvindt. Wanneer de client een HTTP-verzoek doet, bevat het alle informatie die de server nodig heeft om aan dat verzoek te voldoen. De server vertrouwt nooit op informatie van eerdere verzoeken. Als die informatie belangrijk was, zou de klant deze bij een volgend verzoek opnieuw moeten verzenden. Staatloosheid brengt ook nieuwe kenmerken met zich mee. Het is gemakkelijker om een ​​stateless applicatie te distribueren over load-balanced servers. Een stateless applicatie is ook gemakkelijk te cachen.

Er zijn eigenlijk twee soorten staten. Toepassingsstatus die op de client leeft en bronstatus die op de server leeft.

Een webservice hoeft zich alleen zorgen te maken over uw applicatiestatus wanneer u daadwerkelijk een verzoek indient. De rest van de tijd weet het niet eens dat je bestaat. Dit betekent dat wanneer een client een verzoek doet, het alle applicatiestatussen moet bevatten die de server nodig heeft om het te verwerken.

De bronstatus is voor elke client hetzelfde en de juiste plaats is op de server. Wanneer u een afbeelding naar een server uploadt, maakt u een nieuwe bron: de nieuwe afbeelding heeft zijn eigen URI en kan het doelwit zijn van toekomstige verzoeken. U kunt deze bron ophalen, wijzigen en verwijderen via HTTP.

Ik hoop dat dit helpt om te onderscheiden wat staatloosheid en verschillende staten betekenen.

Antwoord 3, autoriteit 15%

Zeggen ze alleen dat je geen gegevensopslag op sessie-/applicatieniveau gebruikt???

Nee. Dat zeggen ze niet op een triviale manier.

Ze zeggen dat je geen ‘sessie’ definieert. Log niet in. Log niet uit. Verstrek referenties bij het verzoek. Elk verzoek staat op zichzelf.

Je hebt nog steeds datastores. U heeft nog steeds authenticatie en autorisatie. U verspilt gewoon geen tijd met het opzetten van sessies en het onderhouden van de sessiestatus.

Het punt is dat elk verzoek (a) volledig op zichzelf staat en (b) triviaal kan worden uitbesteed aan een gigantische parallelle serverfarm zonder echt werk. Apache of Squid kunnen RESTful-verzoeken blindelings en met succes doorgeven.

Wat als ik een wachtrij met berichten had, en mijn gebruiker wilde de berichten lezen, maar terwijl hij ze las, bepaalde berichten van afzenders wilde blokkeren voor de duur van zijn sessie?

Als de gebruiker een filter wil, geef het filter dan gewoon op bij elk verzoek.

Zou het niet logisch zijn om … de server alleen berichten (of bericht-ID’s) te laten verzenden die niet door de gebruiker zijn geblokkeerd?

Ja. Geef het filter op in het RESTful URI-verzoek.

Moet ik echt de hele lijst met afzenders van berichten verzenden om te blokkeren telkens wanneer ik de nieuwe berichtenlijst opvraag?

Ja. Hoe groot kan deze “lijst met te blokkeren berichtenafzenders” zijn? Een korte lijst van PK’s?

Een ontvangen verzoek kan erg groot zijn. Indien nodig kunt u een postverzoek proberen, ook al klinkt het als een soort query.

4, Autoriteit 8%

U hebt absoluut gelijk, ondersteunt volledig statieke interacties met de server heeft een extra last op de klant. Als u echter overweegt een aanvraag te schalen, is het berekeningsvermogen van de clients recht evenredig met het aantal klanten. Daarom is het schalen naar hoge aantallen van klanten veel haalbaar.

Zodra u een klein beetje verantwoordelijkheid op de server plaatst om wat informatie te beheren met betrekking tot interacties van een specifieke klant, kan die last snel groeien om de server te consumeren.

Het is een afweg.

Antwoord 5, autoriteit 6%

REST is erg abstract. Het helpt om een ​​aantal goede, eenvoudige, praktijkvoorbeelden te hebben.

Neem bijvoorbeeld alle belangrijke apps voor sociale media — Tumblr, Instagram, Facebook en Twitter. Ze hebben allemaal een eeuwig scrollende weergave waarbij hoe verder je naar beneden scrolt, hoe meer inhoud je ziet, steeds verder terug in de tijd. We hebben echter allemaal dat moment ervaren waarop je verliest waar je naar toe was gescrolld, en de app zet je terug naar de top. Alsof je de app afsluit, en als je hem opnieuw opent, sta je weer bovenaan.

De reden hiervoor is dat de server uw sessiestatus niet heeft opgeslagen. Helaas is uw schuifpositie zojuist in het RAM op de client opgeslagen.

Gelukkig hoef je niet opnieuw in te loggen wanneer je opnieuw verbinding maakt, maar dat is alleen omdat je aan de clientzijde ook opgeslagen inlogcertificaat niet is verlopen. Verwijder en installeer de app opnieuw, en u zult opnieuw moeten inloggen, omdat de server uw IP-adres niet aan uw sessie heeft gekoppeld.

Je hebt geen inlogsessie op de server, omdat ze zich houden aan REST.

De bovenstaande voorbeelden hebben helemaal geen webbrowser nodig, maar aan de achterkant communiceren de apps via HTTPS met hun hostservers. Mijn punt is dat REST geen cookies en browsers enz. nodig heeft. Er zijn verschillende manieren om de sessiestatus aan de clientzijde op te slaan.

Maar laten we het even over webbrowsers hebben, want dat brengt nog een groot voordeel van REST naar voren waar niemand het hier over heeft.

Als de server probeerde de sessiestatus op te slaan, hoe moet hij dan elke individuele client identificeren?

Het kon hun IP-adres niet gebruiken, omdat veel mensen datzelfde adres op een gedeelde router zouden kunnen gebruiken. Dus hoe dan?

Het kan om vele redenen geen MAC-adres gebruiken, niet in de laatste plaats omdat je tegelijkertijd op meerdere verschillende Facebook-accounts in verschillende browsers plus de app kunt inloggen. De ene browser kan zich gemakkelijk voordoen als een andere, en MAC-adressen zijn net zo gemakkelijk te spoofen.

Als de server een status aan de clientzijde moet opslaan om u te identificeren, moet deze deze langer in het RAM-geheugen opslaan dan alleen de tijd die nodig is om uw verzoeken te verwerken, anders moet hij die gegevens in de cache opslaan. Servers hebben beperkte hoeveelheden RAM en cache, om nog maar te zwijgen van de processorsnelheid. De status aan de serverzijde voegt exponentieel toe aan alle drie. En als de server een status over uw sessies gaat opslaan, moet deze deze apart opslaan voor elke browser en app waarmee u momenteel bent aangemeld, en ook voor elk ander apparaat dat u gebruikt.

Dus… ik hoop dat je nu begrijpt waarom REST zo belangrijk is voor schaalbaarheid.
Ik hoop dat je kunt beginnen te begrijpen waarom de server-side sessiestatus voor de schaalbaarheid van de server is wat aangelaste aambeelden zijn voor de acceleratie van auto’s.

Waar mensen in de war raken, is door te denken dat ‘staat’ verwijst naar informatie die is opgeslagen in een database. Nee, het verwijst naar alle informatie die zich in het RAM-geheugen van de server moet bevinden wanneer u deze gebruikt.

Antwoord 6, autoriteit 4%

Ik zie dat het basisprobleem hier is dat je Sessieverwisselt met Status. En hoewel REST specificeert dat u de StatusNIET op de server moet opslaan, weerhoudt niets u ervan om een ​​Sessievan een gebruiker op te slaan.

Het beheren van de Statusop de server betekent dat uw server precies weet wat de client doet (welke pagina ze bekijken in welke sectie van de applicatie). En dit is wat u niet zou moeten doen.

Ik ben het eens met de andere mensen die zeggen dat je de sessie-opslag tot een minimum moet beperken; en hoewel dat gezond verstand is, is het eigenlijk ook afhankelijk van de toepassing.
Kortom, u kunt dus nog steeds een sessie houden met gegevens in de cache om de verzoeken af ​​te handelen met minder belasting van de server, en de authenticatie beheren door een tijdelijk authenticatie-/toegangstoken te verstrekken dat de client kan gebruiken. Telkens wanneer de sessie/token is verlopen, genereert u een nieuwe en vraagt ​​u de klant om deze te gebruiken.

Iemand zou kunnen beweren dat de client het token beter zou moeten genereren. Ik zeg dat het in beide richtingen werkt, en dat het afhangt van de toepassing en wie met de API gaat werken.

Ook het bewaren van enkele gevoelige sessiegegevens op de server zou de juiste manier moeten zijn om te doen. U kunt er niet op vertrouwen dat de klant zijn winkelwagentje houdt dat (bijvoorbeeld) een veld met de naam “isFreeGift” bevat. Dergelijke informatie moet op de server worden bewaard.

De videolink van Santanu Deyin zijn antwoord is nuttig. Bekijk het als je dat nog niet hebt gedaan.

Een kanttekening: het lijkt erop dat alle reeds gegeven antwoorden geen rekening houden met het feit dat sommige bewerkingen een zware belasting van de server kunnen veroorzaken. Dat is relevant in termen van stroomverbruik, hardwareverbruik en kosten (voor servers die worden gehuurd per CPU-cyclus). Een goede ontwikkelaar mag niet lui zijn bij het optimaliseren van zijn applicatie, zelfs als de bewerking heel snel kan worden uitgevoerd op een moderne CPU op een gehuurde server waarvoor hij de elektriciteits- en onderhoudsrekening niet betaalt.

Hoewel de vraag een paar jaar oud is, hoop ik dat mijn antwoord nog steeds nuttig is.

Antwoord 7, autoriteit 4%

Er is geen lepel.

Denk niet aan staatloosheid zoals “alje spullen keer op keer naar de server sturen”. Echt niet. Er zal altijd een staat zijn – de database zelf istenslotte een soort staat, je bent een geregistreerde gebruiker, dus elke set informatie aan de clientzijde is niet geldig zonder de serverkant. Technisch gezien ben je nooit echt staatloos.

Het inlogdebat

Wat betekent het zelfs om een ​​sessie niet bij te houden – en elke keer in te loggen?

Sommigen bedoelen “elke keer het wachtwoord verzenden”, dat is gewoon dom. Sommigen zeggen “nee natuurlijk niet, stuur in plaats daarvan een token” – kijk, de PHP-sessie doet bijna precies dat. Het stuurt een sessie-IDwat een soort tokenis en het helpt je om je persoonlijke dingen te bereiken zonder u/pw elke keer opnieuw te verzenden. Het is ook redelijk betrouwbaar en goed getest. En ja, handig, wat een nadeel kan worden, zie volgende paragraaf.

Verklein de voetafdruk

Wat u in plaats daarvan moet doen, en wat echt logisch is, is de voetafdruk van uw webserver tot een minimum beperken. Talen zoals PHP maken het heel gemakkelijk om alles gewoon in de sessieopslag te proppen – maar sessies hebben een prijskaartje. Als je meerdere webservers hebt, moeten ze sessie-informatie delen, omdat ze ook de belasting delen – elk van hen moet mogelijk het volgende verzoek uitvoeren.

Een gedeelde opslag is een must. De server moet op zijn minst weten of iemand is ingelogd of niet. (En als je de database elke keer lastigvalt als je dit moet beslissen, ben je praktisch gedoemd te mislukken.) Gedeelde opslag moet veel sneller zijn dan de database. Dit brengt de verleiding met zich mee: oke, ik heb een zeer snelle opslag, waarom zou ik daar niet alles doen?– en dat is waar het op de andere manier smerig gaat.

Dus je zegt, beperk sessieopslag tot het minimum?

Nogmaals, het is jouw beslissing. Je kunt er dingen opslaan om prestatieredenen (database is bijna altijd langzamer dan Redis), je kunt informatie redundant opslaan, je eigen caching implementeren, wat dan ook – houd er rekening mee dat webservers een grotere belasting zullen hebben als je veel rotzooi opslaat op hen. Als ze breken onder zware belasting (en dat zullen ze ook doen), verlies je waardevolle informatie; met de REST-manier van denken, alles wat er in dit geval gebeurt, is dat de klant hetzelfde (!) verzoek opnieuw verzendt en deze keer wordt geserveerd.

Hoe doe je het dan goed?

Hier is geen one-fits-all oplossing. Ik zou zeggen kies een niveau van staatloosheid en ga daarmee akkoord. Sessies zijn misschien geliefd bij sommigen en gehaat door anderen, maar ze gaan nergens heen. Stuur bij elk verzoek zoveel informatie als zinvol is, misschien een beetje meer; maar interpreteer staatloosheid niet als het niet hebben van een sessie, noch als elke keer inloggen. Op de een of andere manier moet de server weten dat jij het bent; PHP-sessie-ID’s zijn een goede manier, handmatig gegenereerde tokens zijn een andere.

Denk na en beslis – laat designtrends niet voor je denken.

Antwoord 8, autoriteit 2%

Statloos betekent dat de status van de service niet blijft bestaan ​​tussen volgende verzoeken en reactie. Elk verzoek heeft zijn eigen gebruikersreferenties en wordt individueel geverifieerd. Maar in stateful is elk verzoek bekend van elk eerder verzoek. Alle stateful-verzoeken zijn sessiegericht, d.w.z. dat elk verzoek wijzigingen in eerdere verzoeken moet kennen en bewaren.

Bankapplicatie is een voorbeeld van stateful applicatie. Waar de gebruiker eerst inlogt, vervolgens een transactie uitvoert en uitlogt. Als de gebruiker na het uitloggen probeert de transactie uit te voeren, zal hij dit niet kunnen doen.

Ja, het http-protocol is in wezen een stateloos protocol, maar om het stateful te maken, maken we gebruik van HTTP-cookies. Dus standaard is SOAP. Maar het kan ook stateful worden gemaakt, afhankelijk van het framework dat je gebruikt.

HTTP is stateless, maar toch kunnen we de sessie in onze java-applicatie behouden door een ander mechanisme voor het volgen van sessies te gebruiken.

Ja, we kunnen ook een sessie in de webservice onderhouden, of het nu REST of SOAP is. Het kan worden geïmplementeerd met behulp van een bibliotheek van derden of u kunt het zelf implementeren.

Genomen van http://gopaldas.org/ webservices/soap/webservice-is-stateful-or-stateless-rest-soap

Antwoord 9

Bekijk deze presentatie.

http://youtu.be/MRxTP-rQ-S8

Volgens dit patroon – creëer tijdelijke rustgevende bronnen om de status te beheren als en wanneer dat echt nodig is. Vermijd expliciete sessies.

Antwoord 10

Het belangrijkste verschil tussen stateless en stateful is dat de gegevens elke keer worden teruggestuurd naar de server. In het geval van stateless moet de client alle informatie verstrekken, dus het kan zijn dat er in elk verzoek veel parameters moeten worden doorgegeven. In Stateful geeft de cliet die parameters eenmaal door en ze worden door de server onderhouden totdat ze opnieuw door de client worden gewijzigd.

IMO, API zou stateless moeten zijn, wat het mogelijk maakt om heel snel op te schalen.

Antwoord 11

U moet de clientsessie aan de clientzijde beheren. Dit betekent dat je bij elk verzoek authenticatiegegevens moet verzenden en dat je waarschijnlijk, maar niet noodzakelijk, een in-memory cache op de server hebt, die authenticatiegegevens koppelt aan gebruikersinformatie zoals identiteit, machtigingen, enz…

Deze REST staatloosheidsbeperkingis erg belangrijk . Zonder deze beperking toe te passen, zal uw server-side applicatie niet goed schalengoed, omdat het onderhouden van elke afzonderlijke clientsessie zal zijn achilleshielzijn.

Antwoord 12

Wanneer u een RESTful-service ontwikkelt, moet uw gebruiker worden geverifieerd om in te loggen. Een mogelijke optie zou zijn om de gebruikersnaam en het wachtwoord elke keer dat u van plan bent een gebruikersactie uit te voeren, te verzenden. In dit geval zal de server helemaal geen sessiegegevens opslaan.

Een andere optie is om een ​​sessie-id op de server te genereren en deze naar de client te sturen, zodat de client een sessie-id naar de server kan sturen en zich daarmee kan authenticeren. Dit is veel veiliger dan elke keer een gebruikersnaam en wachtwoord te verzenden, want als iemand die gegevens in handen krijgt, kan hij/zij zich voor de gebruiker voordoen totdat de gebruikersnaam en het wachtwoord zijn gewijzigd. Je zou kunnen zeggen dat zelfs de sessie-ID kan worden gestolen en dat de gebruiker in dat geval wordt nagebootst en je hebt gelijk. In dit geval is het imiteren van de gebruiker echter alleen mogelijk zolang de sessie-ID geldig is.

Als de RESTful API gebruikersnaam en wachtwoord verwacht om gebruikersnaam en wachtwoord te wijzigen, kan de hacker de echte gebruiker niet buitensluiten, zelfs als iemand zich voordoet als de gebruiker met behulp van de sessie-ID.

Een sessie-ID kan worden gegenereerd door eenrichtingsvergrendeling (encryptie) van iets dat de gebruiker identificeert en de tijd aan de sessie-ID toe te voegen, op deze manier kan de vervaltijd van de sessie worden gedefinieerd.

De server kan wel of niet sessie-ID’s opslaan. Als de server de sessie-ID opslaat, zou dit natuurlijk in strijd zijn met de criteria die in de vraag zijn gedefinieerd. Het is echter alleen belangrijk om ervoor te zorgen dat de sessie-ID kan worden gevalideerd voor de gegeven gebruiker, wat niet nodig is om de sessie-ID op te slaan. Stel je een manier voor waarop je een eenrichtingscodering hebt van e-mail, gebruikers-ID en enkele gebruikersspecifieke privégegevens, zoals favoriete kleur, dit zou het eerste niveau zijn en op de een of andere manier de gebruikersnaamdatum toevoegen aan de versleutelde reeks en een twee- manier encryptie. Het resultaat is dat wanneer een sessie-ID wordt ontvangen, het tweede niveau kan worden gedecodeerd om te kunnen bepalen welke gebruikersnaam de gebruiker beweert te zijn en of de sessietijd juist is. Als dit geldig is, kan het eerste niveau van codering worden gevalideerd door die codering opnieuw te doen en te controleren of deze overeenkomt met de tekenreeks. U hoeft hiervoor geen sessiegegevens op te slaan.

Antwoord 13

Het hele concept is anders… U hoeft geen sessies te beheren als u het RESTFul-protocol probeert te implementeren. In dat geval is het beter om bij elk verzoek een authenticatieprocedure uit te voeren (terwijl er extra kosten aan verbonden zijn in termen van prestaties – het hashen van een wachtwoord zou een goed voorbeeld zijn. geen probleem…). Als u sessies gebruikt, hoe kunt u de belasting dan over meerdere servers verdelen? Ik wed dat het RESTFul-protocol bedoeld is om sessies te elimineren – je hebt ze niet echt nodig… Daarom wordt het “stateless” genoemd. Sessies zijn alleen nodig als je niets anders dan Cookie op een client-side kunt opslaan nadat een verzoek is gedaan (neem als voorbeeld een oude, niet Javascript/HTML5-ondersteunende browser). In het geval van een “full-featured” RESTFul-client is het meestal veilig om base64(login:password)op een clientzijde (in het geheugen) op te slaan totdat de applicatie nog steeds is geladen – de applicatie wordt gebruikt om toegang te krijgen naar de enige host en de cookie kan niet worden aangetast door scripts van derden…

Ik zou het ten zeerste aanbevelen om cookie-authenticatie voor RESTFul-services uit te schakelen… bekijk Basic/Digest Auth – dat zou genoeg moeten zijn voor op RESTFul gebaseerde services.

Antwoord 14

REST is staatloos en onderhoudt geen statussen tussen de verzoeken. Clientcookies / headers zijn ingesteld om de gebruikersstatus te behouden, zoals authenticatie. Stel dat de gebruikersnaam en het wachtwoord van de klant worden gevalideerd door een authenticatiemechanisme van een derde deel – OTP-generatie van het tweede niveau, enz. Zodra de gebruiker is geverifieerd – komen headers / cookies tot rust op het service-eindpunt dat wordt weergegeven en kunnen we aannemen dat de gebruiker auth is, omdat de gebruiker geldige headers / cookies krijgt . Nu wordt bepaalde informatie van de gebruiker, zoals IP, in de cache bewaard en daarna, als het verzoek van hetzelfde IP-adres (mac-adres) komt voor de vermelde bronnen, is de gebruiker toegestaan. En de cache wordt gedurende een bepaalde tijd bijgehouden, die ongeldig wordt zodra de tijd verstrijkt. Dus ofwel cache kan worden gebruikt of DB-items kunnen worden gebruikt om informatie over de verzoeken te bewaren.

Antwoord 15

Statloos betekent hier dat de status- of metagegevens van het verzoek niet aan de serverzijde worden bijgehouden. Door elk verzoek of elke gebruikersstatus op de server te behouden, zou dit leiden tot prestatieknelpunten. Server is zojuist gevraagd met de vereiste attributen om specifieke bewerkingen uit te voeren.

Als je sessies wilt beheren of gebruikers een aangepaste ervaring wilt bieden, moet je een aantal metagegevens of de status van de gebruikersvoorkeuren van de gebruiker, de geschiedenis van eerdere verzoeken, bijhouden. Dit kan worden gedaan door cookies, verborgen attributen of in een sessieobject te behouden.

Dit kan de status van de gebruiker in de applicatie bijhouden of bijhouden.

Hopelijk helpt dit!