web applicatie

Van Wikipedia, de gratis encyclopedie
Spring naar navigatie Spring naar zoeken

Een webapplicatie (ook wel online applicatie , webapplicatie of kortweg webapp ) is een applicatieprogramma gebaseerd op het client-server model . In tegenstelling tot klassieke desktopapplicaties worden webapplicaties niet lokaal op de computer van de gebruiker geïnstalleerd. Een deel van de gegevensverwerking vindt plaats op een externe webserver . De resultaten van de gegevensverwerking worden overgebracht naar de lokale clientcomputer van de gebruiker ( thin client ). Een webapplicatie wordt meestal gebruikt via een webbrowser . Deze communiceert met de webserver meestal via het HTTP-protocol .

In tegenstelling tot desktopapplicaties hebben webapplicaties geen speciaal besturingssysteem op de computer van de gebruiker nodig. Sommige web-apps vereisen echter up-to-date webbrowsers of speciale runtime-omgevingen , zoals: B. JavaScript of Flash .

Delen van de uitvoeringslogica moeten echter niet eerst op de server worden uitgevoerd, maar eerder op de clientcomputer, vooral voor voorlopige validatie . Op deze manier worden invoerfouten lokaal herkend. Feedback aan de gebruiker wordt onmiddellijk gegeven zonder te wachten op een antwoord van een externe server. Met behulp van AJAX-technologie worden alleen delen van de inhoud in de webclient bijgewerkt zonder dat de website opnieuw hoeft te worden opgeroepen. Een dergelijke distributie kan worden uitgebreid tot een fat client-architectuur (ziesingle-page webapplicaties ).

Het gebruik van de afkorting web-app breidt zich uit met de verspreiding van internet-enabled, mobiele smartphones en tabletcomputers .

functionaliteit

Algemene functionaliteit

Schematische gegevensstroom in een client-server-webtoepassing

U start een webapplicatie door z. B. voert de URL van de webserver in de browser in en stuurt een verzoek ( HTTP-verzoek ). De webserver ontvangt de aanvraag en stuurt deze door naar de webapplicatie. Deze genereert of laadt de HTML-broncode van een website, die wordt teruggestuurd van de webserver naar de browser van de gebruiker (HTTP-reactie). Deze website is de grafische gebruikersinterface van de webapplicatie. Als je kijkt naar de laagarchitectuur van een webapplicatie, dan wordt de presentatielaag uitgevoerd in de webbrowser (thin client). Delen van de logische laag en gegevensopslag worden op de server uitgevoerd.

Door op een hyperlink op deze website te klikken of een formulier in te vullen en te verzenden, start u een nieuwe aanvraag bij de webserver. Meestal is aanvullende informatie, zoals: B. de invoer in het formulier (HTTP POST), de parameters van de link (HTTP GET) en de gegevens van een HTTP-cookie worden verzonden naar de webserver en verwerkt als invoer door de webapplicatie. Via interfaces zoals: B. de Common Gateway Interface of FastCGI , de webapplicatie is geïntegreerd in de webserver. Op deze manier worden verzoeken doorgestuurd naar de webapplicatie en wordt de output van de webapplicatie als reactie teruggestuurd. De verwerking van zo'n HTTP-request door de webapplicatie wordt ook wel de request cycle genoemd .

Bij het gebruik van web-apps worden sessiegegevens (bijvoorbeeld bestelgegevens uit een webshop) op de server opgeslagen in databases of bestanden. Gebruikersgerelateerde gegevens kunnen ook aan de clientzijde worden opgeslagen met behulp van HTTP-cookies. Sessie-informatie aan de serverzijde verbruikt serverbronnen per actieve gebruikerssessie. Server-side sessie-informatie maakt het ook moeilijk om de webapplicaties horizontaal te schalen. Alternatieve architecturale benaderingen voor webapplicaties zoalssingle-page webapplicaties of het REST-paradigma combineren daarom de server-side met de client-side uitvoering.

Terwijl een webapplicatie ooit alleen de HTML-broncode van de website genereerde, zijn er sindsdien ook afbeeldingen, animaties, video's, audiobestanden en PDF-documenten gegenereerd.

Hoe mobiele web-apps werken

Webapplicaties hebben het voordeel dat ze op elk eindapparaat kunnen worden bediend. Het eindapparaat vereist een webbrowser die de vereiste webstandaarden ondersteunt (zoals HTML5 of JavaScript ). Op het gebied van mobiele applicaties zijn er platformspecifieke interfaces voor applicatieontwikkeling. Voor elk doelplatform moet een aparte implementatie worden geïmplementeerd. Dergelijke implementaties staan ​​bekend als native apps. Webapplicaties daarentegen kunnen op alle platformen draaien. Ze staan ​​bekend als een mobiele web-app.

architectuur

Een webapplicatie draait meestal op de webserver, maar kan ook worden uitbesteed aan een of meer applicatieservers, die worden bediend door een of meer webservers met gebruikersverzoeken. Er kan een onderscheid worden gemaakt tussen twee architecturen:

Standalone
De webtoepassing is een onafhankelijk binair programma of een script dat wordt geïnterpreteerd door een onafhankelijk binair programma, dat voor elke aanvraag opnieuw wordt gestart. Dergelijke toepassingen worden meestal CGI-programma's genoemd.
Geïntegreerd
De webapplicatie is onderdeel van de webserver of een script dat door de webserver wordt geïnterpreteerd. Er hoeft niet meer voor elke aanvraagcyclus een programma te worden gestart. Voorbeelden: PHP , Perl , Python , Ruby (elk geïnterpreteerd door de overeenkomstige modules van de webserver), Java Servlet , JavaServer Pages of ASP.NET .

Distributie varianten

Klassiek wordt een webapplicatie steeds vaker aan de serverkant uitgevoerd. Er zijn ook benaderingen als distributievarianten die zorgen voor een meer client-zware uitvoering van een webapplicatie. De webclient wordt een steeds onafhankelijkere eenheid om server-side resources te ontlasten [1] . Deze benaderingen zijn vooral nuttig voor B2C- toepassingen, zoals: B. Facebook of Gmail - relevant, aangezien bij dergelijke projecten grote aantallen gebruikers te verwachten zijn. Ook de gebruikerservaring kan worden verbeterd, omdat niet bij elke interactie met de webclient een client-server communicatie hoeft te worden geactiveerd, wat de reactietijden van webapplicaties vertraagt.

Rijke internettoepassing
Een rijke internettoepassing (RIA) vereist per definitie een hogere mate van programmalogica in de client, bijvoorbeeld om berekeningen op de client uit te voeren in plaats van op de server. Strikt genomen zijn webprojecten met webapplicaties die gebruikmaken van JavaScript (inclusief AJAX), Java-applets, Flash-animaties, ActiveX-plug-ins en dergelijke ook RIA's, mits deze elementen betrokken zijn bij de interactie met de gebruiker.
Webapplicaties met één pagina
Eensingle-page webapplicatie combineert de RIA-aanpak met webservices. De volledige presentatielaag van een webapplicatie wordt aan de clientzijde geïmplementeerd. Verdere functionaliteiten van het technische concept aan de serverzijde en gegevensopslag als tussenopslag voor offline gebruik van de webapplicaties kunnen ook op de client worden uitgevoerd. [1] Het is dus een fat client-architectuur voor webapplicaties. Bij deze aanpak is de webserver alleen verantwoordelijk voor de distributie van Javascript, CSS en afbeeldingsbestanden en voor het ter beschikking stellen van gebruikersgegevens via webservices (bijvoorbeeld via REST API ). Dergelijke benaderingen resulteren vaak in zogenaamde hybride apps . Het combineert de voordelen van native apps en webapps door toegang te krijgen tot de softwarecomponenten van het mobiele apparaat en tegelijkertijd verschillende platforms te bedienen.

Grensscheiding

webservice
Bij een webservice levert een webserver informatie in een gestructureerd formaat die niet primair bedoeld is voor directe weergave. Het gebruik van XML alleen is niet voldoende om het te onderscheiden van een webapplicatie, aangezien deze sinds de introductie vanXHTML ook gebruik maken van XML . Bij een webservice zijn XML-gegevens echter bedoeld voor verdere verwerking in elk programma op de client. Zelfs interactie met een gebruiker is hier geen verplichte vereiste. Het JSON- formaat wordt ook gebruikt als het gegevensformaat. Dit biedt voordelen voor gebruik door een op Javascript gebaseerde webclient, aangezien XML-structuren niet geparseerd hoeven te worden.

vergelijking

voordelen

Voor webapplicaties is alleen een webbrowser op de computer van de gebruiker nodig, die meestal al beschikbaar is. In tegenstelling tot conventionele client-server-applicaties is er geen verdere software-installatie nodig, afgezien van browser plug-ins zoals Flash. Hierdoor bereiken webapplicaties een hoge mate van platformonafhankelijkheid , mits veel browsers ondersteund worden.

Als de logica van een webapplicatie gewijzigd moet worden, zijn wijzigingen slechts op één centraal punt - op de webserver - nodig, wat een gunstig effect heeft op de onderhoudskosten. Dit levert ook veiligheidsvoordelen op: hiaten in de beveiliging kunnen onmiddellijk worden verholpen, en zelfs als de webtoepassing volledig is gecompromitteerd, worden in het algemeen geen andere programma's op het gebruikerssysteem in gevaar gebracht.

nadeel

Om een ​​webapplicatie te gebruiken is een verbinding met de webserver nodig. De datasnelheid van de verbinding moet ook worden ontworpen voor de vereisten van de webapplicatie. Dit feit sluit webapplicaties uit voor een aantal gebruiksscenario's, zoals: B. mobiel offline gebruik per definitie. Webapplicaties identificeren geregistreerde gebruikers op sessie-ID. Dit kan leiden tot beveiligingsproblemen (zie hieronder).

Idealiter zouden webapplicaties goed moeten werken met alle webbrowsers. In de praktijk is dit echter geenszins vanzelfsprekend, aangezien browsers HTML anders interpreteren - ondanks bestaande standaarden (W3C). De kleine afwijking in de weergave tussen verschillende browsers is meestal onbeduidend, de verschillen in de JavaScript-interpretatie zijn verwoestender, daarom moeten vaak browser-switches worden gebruikt, soms zelfs voor verschillende browserversies. Bovendien is alleen asynchrone verwerking mogelijk vanwege de hierboven getoonde aanvraagcyclus, die een aantal toepassingsgebieden (bijvoorbeeld video's bewerken) als webapplicatie uitsluit of aanzienlijk bemoeilijkt. Bovendien zijn de opties voor het implementeren van gebruikersinteractie-opties en toegang tot de hardwarebronnen van de klant aanzienlijk beperkter.

verhaal

Voor een webapplicatie is het nodig om gebruikersinvoer te ontvangen. De HTML-formulieren die tegenwoordig voor dit doel worden gebruikt, zijn voor het eerst opgenomen in het concept voor "HTML +" van 8 november 1993. [2] Maar de eerste HTML-versie van Tim Berners-Lee bood al een manier om parameters met de "Isindex"-tag naar de webserver te sturen. De parameters werden toegevoegd aan de URL, de voorloper van de HTTP Get-methode. Het eerste grote systeem dat hiervan gebruik maakte, was hoogstwaarschijnlijk een webinterface naar de "SPIRES-HEP", een database aan de Stanford University . [3] Deze voorloper van alle hedendaagse webapplicaties ging in 1991 online.

De eerste webbrowser die uitgebreide ondersteuning voor HTML-formulieren implementeerde, was de NCSA Mosaic 2.0 in december 1993; op dat moment de browser met de grootste populariteit. De eerste server-side interface voor het ontvangen van formuliergegevens was "htbin". Dit werd op 4 november 1993 gepubliceerd als onderdeel van versie 2.13 van de W3C HTTP-server. De CGI-interface volgde op 11 februari 1994 in release 2.15 beta, die nog steeds in gebruik is. CGI is onafhankelijk van de gebruikte programmeertaal. C of Perl werd gebruikt voor de eerste webapplicaties. Perl bood zichzelf aan vanwege de krachtige functies voor het verwerken van tekenreeksen.

De eerste webapplicatie die door het grote publiek werd opgemerkt, is ook afkomstig van Stanford University. Twee studenten ontwikkelden de webdirectory Yahoo vanuit hun persoonlijke bladwijzerbeheer. Ze gebruikten Perl als hun programmeertaal.

In de daaropvolgende jaren waren er verdere ontwikkelingen van de CGI-interface, die de prestaties verbeterden. In het voorjaar van 1997 publiceerde Sun Microsystems de servlettechnologie. Servlets zijn Java-programma's die erg lijken op CGI-programma's. Het belangrijkste verschil is dat een HTTP-verzoek niet in een apart proces wordt verwerkt, maar alleen in een aparte thread. Dit leverde een enorme prestatiewinst op.

Het proces van het samenstellen van websites uit HTML-code die permanent in de programmacode was opgeslagen, vormde echter een groot probleem: het was omslachtig om te programmeren en liet geen scheiding toe tussen logica en inhoud. Dit probleem is door meerdere kwartalen op vergelijkbare wijze opgelost. De programmacode voor de dynamisch gegenereerde uitvoer was ingebed in de anders statische HTML. Deze benadering wordt gevolgd door de PHP-taal , die rond 1997 voortkwam uit een op Perl gebaseerd project, JavaServer Pages , die op servlets is gebaseerd, en Active Server Pages (ASP) van Microsoft.

Ten tijde van de grote internethausse rond de millenniumwisseling, beleefden webapplicaties een enorme boost. Veel van de door de beurs geroemde New Economy- bedrijven bouwden hun bedrijfsmodel op een webapplicatie. De overdreven verwachtingen leidden in 2001 tot het uiteenspatten van de zogenaamde dotcom-zeepbel . Gedurende deze tijd kunnen webapplicaties zoals B. eBay , Yahoo en Google werden geboren, die tegenwoordig een natuurlijk onderdeel van het internetleven zijn geworden.

Sinds de komst van AJAX worden de client-side resources steeds meer meegenomen in de werking van de applicatie in webapplicaties. De wens naar meer interactiviteit maakte het noodzakelijk om meer content via AJAX te herladen en de DOM-structuur van de huidige weergave dynamisch uit te breiden. De hiervoor benodigde besturingslogica wordt met JavaScript geïmplementeerd en in de webbrowser uitgevoerd. Als gevolg hiervan is de klassieke paginawisseling niet langer absoluut noodzakelijk om nieuwe pagina-inhoud weer te geven. Het paradigma vansingle-page webapplicaties is gebaseerd op een uitsluitend client-side uitvoering van de presentatielaag van een webapplicatie.

Webengineering kwam naar voren als een academische discipline, die methoden voor software-engineering overdraagt ​​op de ontwikkeling van webapplicaties.

Kaders en hulpmiddelen

Er zijn verschillende frameworks voor het maken van webapps:

De competenties van klassieke webdesigners en mobiele webapp-ontwikkelaars verschillen sterk in het punt dat de focus bij mobiel internet ligt op de context en niet (alleen) op de inhoud. Vooral de gebruikersinterface is een belangrijke factor bij de ontwikkeling van mobiele webapps.

veiligheid

Beveiliging van webapplicaties is een te breed gebied om hier te behandelen. Daarom is deze sectie beperkt tot de beschrijving van bekende aanvalsmogelijkheden in verband met webapplicaties. Aanvallen op een webapplicatie kunnen worden voorkomen door hiaten in de beveiliging tijdens de implementatie te vermijden, of bemoeilijkt of verdedigd worden door het gebruik van upstream- webapplicatie-firewalls .

De volgende aanvallen zijn niet gericht tegen de webapplicatie zelf, maar zijn vaak in de omgeving te vinden:

Voorbeelden

Enkele voorbeelden zijn te vinden in de categorie: webapplicatie .

web links

Individueel bewijs

  1. a b Beschrijving van de wijziging in webapplicaties (SPA)
  2. ^ Een overzicht van de HTML + documentindeling
  3. slac.stanford.edu