Web application

from Wikipedia, the free encyclopedia

A web application (also online application , web application or web app for short ) is an application program based on the client-server model . Unlike classic desktop applications , web applications are not installed locally on the user's computer. The data processing takes place partly on a remote web server . The results of the data processing are transferred to the user's local client computer ( thin client ). A web application is mostly used via a web browser . This usually transmits data with the web server using the HTTP protocol .

Unlike desktop applications , web applications do not require a special operating system on the user's computer. However, some web apps require up-to-date web browsers or special runtime environments , such as B. JavaScript or Flash .

Parts of the execution logic should, however, not be executed in the server first, but rather in the client computer, especially for validation . Input errors are recognized locally in this way. Feedback to the user is given immediately without waiting for a reply from a remote server. Using AJAX technology only partial areas of content on the Web client updates without the website again having to call. Such a distribution can be expanded up to a fat client architecture (see single-page web applications ).

With the spread of internet-enabled, mobile smartphones and tablet computers , the use of the abbreviation web app is increasing.

functionality

General functionality

Schematic data flow in a client-server web application

You start a web application by z. B. enters the URL of the web server in the browser and sends a request ( HTTP request ). The web server receives the request and forwards it to the web application. This generates or loads the HTML source code of a website, which is sent back from the web server to the user's browser (HTTP response). This website is the graphical user interface of the web application. If you consider the layer architecture of a web application, the presentation layer is executed in the web browser (thin client). Parts of the logic layer and data storage are carried out on the server.

By clicking a hyperlink on this website or filling out and submitting a form, you start a new request to the web server. Typically, additional information, such as B. the entries made in the form (HTTP POST), the parameters of the link (HTTP GET) and the data of an HTTP cookie are transmitted to the web server and processed as input by the web application. Via interfaces such as B. the Common Gateway Interface or FastCGI , the web application is integrated within the web server. In this way, requests are forwarded to the web application and the output of the web application is sent back in response. The processing of such an HTTP request by the web application is also called the request cycle .

When using web apps, session data (e.g. order data from a web shop) is stored on the server in databases or files. User-related data can also be stored on the client side using HTTP cookies. Server-side session information consumes server resources for each active user session. Server-side session information also makes horizontal scaling of the web applications difficult. Alternative architectural approaches for web applications such as single-page web applications or the REST paradigm therefore combine server-side with client-side execution.

While a web application once only generated the HTML source code of the website, images, animations, videos, audio files and PDF documents have also been generated since then.

How mobile web apps work

Web applications have the advantage that they can be operated on any end device. The end device requires a web browser that supports the required web standards (such as HTML5 or JavaScript ). In the area of ​​mobile applications, there are platform-specific interfaces for application development. A separate implementation must be implemented for each target platform. Such implementations are referred to as native apps. Web applications, on the other hand, can run on all platforms. They are known as a mobile web app.

architecture

A web application usually runs on the web server, but can also be outsourced to one or more application servers, which are served by one or more web servers with user requests. A distinction can be made between two architectures:

Standalone
The web application is an independent binary program or a script interpreted by an independent binary program, which is restarted for each request. Such applications are usually called CGI programs.
Integrated
The web application is part of the web server or a script interpreted by the web server. A program no longer has to be started for each request cycle. Examples: PHP , Perl , Python , Ruby (each interpreted by appropriate modules of the web server), Java Servlet , JavaServer Pages or ASP.NET .

Distribution variants

A web application is traditionally more and more executed on the server side. There are also approaches as distribution variants which provide for a more client-heavy execution of a web application. The web client is becoming an increasingly independent unit in order to relieve server-side resources. These approaches are particularly useful for B2C applications - such as B. Facebook or Gmail - relevant, since such projects can be expected to attract large numbers of users. The user experience can also be improved, since a client-server communication does not have to be triggered for every interaction with the web client, which slows down the reaction times of web applications.

Rich Internet Application
A Rich Internet Application (RIA) requires, by definition, a higher degree of program logic in the client, for example to carry out calculations on the client instead of on the server. Strictly speaking, web projects with web applications that use JavaScript (including AJAX), Java applets, Flash animations, ActiveX plugins and the like. use, including RIAs, provided that these elements are involved in the interaction with the user.
Single-page web applications
A single-page web application combines the RIA approach with web services. The complete presentation layer of a web application is implemented on the client side . Further functionalities of the server-side technical concept as well as data storage as intermediate storage for offline operation of the web applications can also be implemented on the client. It is therefore a fat client architecture for web applications. With this approach, the web server is only responsible for the distribution of Javascript, CSS and image files and for the provision of useful data via web services (e.g. via REST API ). Such approaches often result in so-called hybrid apps . It combines the advantages of native apps and web apps by accessing the software components of the mobile device and serving different platforms at the same time.

Demarcation

Web service
With a web service , a web server provides information in a structured format that is not primarily intended for direct display. The use of XML alone is not sufficient to distinguish it from a web application, as these have also been using XML since the introduction of XHTML . With a web service, however, XML data are intended for further processing in any program on the client. Even interaction with a user is not a mandatory requirement here. The JSON format is also used as the data format . This offers advantages for consumption by a Javascript-based web client, since the parsing of XML structures is no longer necessary.

comparison

advantages

Web applications only require a web browser on the user's computer, which is usually already available. In contrast to conventional client-server applications, no further software installation is necessary, apart from browser plug-ins such as Flash. As a result, web applications achieve a high degree of platform independence , provided that many browsers are supported.

If the logic of a web application has to be changed, changes are only necessary in one central place - on the web server - which has a favorable effect on maintenance costs. This also results in security advantages: security gaps can be rectified immediately, and even if the web application is completely compromised, no other programs on the user system are generally endangered.

disadvantage

A connection to the web server is required to use a web application. The data rate of the connection must also be designed for the requirements of the web application. This fact excludes web applications for a number of usage scenarios, such as B. the mobile offline use, by definition. Web applications identify registered users by session ID. This can lead to security problems (see below).

Ideally, web applications should work correctly with all web browsers, which is not a matter of course, as the browsers interpret HTML differently - despite existing standards (W3C). The slight deviation in the display between different browsers is mostly insignificant, the differences in the JavaScript interpretation are more devastating, which is why browser switches often have to be used, sometimes even for different browser versions. In addition, only asynchronous processing is possible due to the request cycle shown above, which excludes a number of application areas (e.g. editing videos) as a web application or makes it significantly more difficult.

history

For a web application it is necessary to receive user input. The HTML forms used today for this purpose are included for the first time in the draft for "HTML +" of November 8, 1993. But even the first HTML version by Tim Berners-Lee offered a way to send parameters to the web server with the “Isindex” tag. The parameters were appended to the URL, the forerunner of the HTTP Get method. The first major system that made use of this was very likely a web interface to the "SPIRES-HEP", a database at Stanford University . This ancestor of all today's web applications went online in 1991.

The first web browser to implement extensive support for HTML forms was the NCSA Mosaic 2.0 in December 1993; at that time the browser with the greatest popularity. The first server-side interface for receiving form data was "htbin". This was published on November 4, 1993 as part of version 2.13 of the W3C HTTP server. The CGI interface followed on February 11, 1994 in Release 2.15 beta, which is still in use today. CGI is independent of the programming language used. C or Perl was used for the first web applications . Perl offered itself because of the powerful functions for processing character strings.

The first web application to be noticed by the general public also originated at Stanford University. Two students developed the Yahoo web directory from their personal bookmark management . They used Perl as their programming language.

In the following years there were further developments of the CGI interface, which improved the performance. In the spring of 1997, Sun Microsystems published the servlet technology. Servlets are Java programs that are very similar to CGI programs. The main difference is that an HTTP request is not processed in a separate process, but only in a separate thread. This brought a huge gain in performance.

The process of assembling websites from HTML code that was permanently stored in the program code, however, posed a major problem: It was cumbersome to program and did not allow a separation of logic and content. This problem has been resolved in similar ways by several quarters. The program code for the dynamically generated output was embedded in the otherwise static HTML. This approach is followed by the PHP language , which emerged from a Perl-based project around 1997, JavaServer Pages , which are based on servlets, and Active Server Pages (ASP) from Microsoft.

At the time of the great Internet boom around the turn of the millennium, web applications experienced a huge boost. Many of the New Economy companies that have been celebrated by the stock exchange built their business model on a web application. The exaggerated expectations led to the bursting of the so-called dot-com bubble in 2001 . During this time, however, web applications such as B. eBay , Yahoo and Google were born, which have now become a natural part of web life.

Since the arrival of AJAX , the client-side resources have increasingly been included in the operation of the application in web applications. The desire for more interactivity made it necessary to reload more content via AJAX and to dynamically expand the DOM structure of the current view. The control logic required for this is implemented with JavaScript and executed in the web browser. As a result, the classic page change is no longer absolutely necessary in order to display new page content. The paradigm of single-page web applications is based on an exclusively client-side execution of the presentation layer of a web application.

Web engineering has emerged as an academic discipline , which transfers methods of software engineering to the development of web applications.

Frameworks and tools

There are different frameworks for creating web apps:

The competencies of classic web designers and mobile web app developers differ significantly in the point that the focus in the mobile Internet is on the context and not (only) on the content. The user interface in particular is an important factor in the development of mobile web apps.

safety

Web application security is too broad a field to cover here. Therefore, this section is limited to the description of well-known attack possibilities in connection with web applications. Attacks against a web application can be prevented by avoiding security gaps during the implementation, or made more difficult or defended by the use of upstream web application firewalls .

The following attacks are not directed against the web application itself, but can often be found in its environment:

Examples

Some examples can be found in the category: web application .

Web links

Individual evidence

  1. ↑ a b Description of the change in web applications (SPA)
  2. ^ A Review of the HTML + Document Format
  3. ↑ slac.stanford.edu