aboutsummaryrefslogtreecommitdiff
path: root/files/de/learn/server-side/first_steps/introduction/index.html
blob: 29246559417ce0c074e855fc504b1cfdf7938eab (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
---
title: Einführung auf der Serverseite
slug: Learn/Server-side/Erste_Schritte/Introduction
tags:
  - Anfänger
  - Einführung
translation_of: Learn/Server-side/First_steps/Introduction
---
<div>{{LearnSidebar}}</div>

<div>{{NextMenu("Learn/Server-side/First_steps/Client-Server_overview", "Learn/Server-side/First_steps")}}</div>

<p class="summary"><span class="seoSummary">Willkommen zum Einsteigerkurs für serverseitige Programmierung! In diesem ersten Artikel schauen wir uns die serverseitige Programmierung im Überblick an, antworten auf Fragen wie "Was ist das?", "Wie unterscheidet es sich von der Client-Seitigen Programmierung?" und "Warum ist es so nützlich?" Nachdem Du diesen Artikel gelesen hast wirst Du den Einfluss verstehen, den Websites durch die serverseitige Programmierung erhalten.</span></p>

<table class="learn-box standard-table">
 <tbody>
  <tr>
   <th scope="row">Vorraussetzungen:</th>
   <td>Grundlegende Computerkenntnisse. Ein grundlegendes Verständnis davon, was ein Webserver ist.</td>
  </tr>
  <tr>
   <th scope="row">Ziel:</th>
   <td>Sich damit vertraut machen, was serverseitige Programmierung ist, was sie kann und wie sie sich von der clientseitigen Programmierung unterscheidet.</td>
  </tr>
 </tbody>
</table>

<p>Die meisten großen Websites verwenden serverseitigen Code, um bei Bedarf verschiedene Daten dynamisch anzuzeigen, die im Allgemeinen aus einer auf einem Server gespeicherten Datenbank gezogen und an den Client gesendet werden, um über einen bestimmten Code (z.B. HTML und JavaScript) angezeigt zu werden.</p>

<p>Der wahrscheinlich größte Vorteil von serverseitigem Code liegt darin, dass man den Inhalt individuell für jeden Benutzer anpassen kann. Dadurch können zum Beispiel bestimmte Details oder Angebote einer Website für bestimmte User hervorgehoben werden. Des weiteren kann serverseitiger Code die Website benutzerfreundlicher machen, indem zum Beispiel Kreditkarteninformationen oder die Versandadresse für weitere Bestellungen gespeichert werden.</p>

<p>Serverseitiger Code wird auch benötigt, um Interaktionen des Benutzers zu ermöglichen. Hierdurch können z.B. Benachrichtigungen oder Updates per E-Mail oder andere Kanäle versendet werden. All diese Vorteile bringen eine bessere Verknüpfung zwischen Benutzer und Website.</p>

<p>In der heutigen Zeit des Webdevelopments wird es deshalb empfohlen sich auch mit der serverseitigen Programmierung von Websites auseinanderzusetzen.</p>

<h2 id="What_is_server-side_website_programming">What is server-side website programming?</h2>

<p>Web browsers communicate with <a href="/en-US/docs/Learn/Common_questions/What_is_a_web_server" rel="noreferrer">web servers</a> using the <strong>H</strong>yper<strong>T</strong>ext <strong>T</strong>ransfer <strong>P</strong>rotocol ({{glossary("HTTP")}}). When you click a link on a web page, submit a form, or run a search, an <strong>HTTP request</strong> is sent from your browser to the target server.</p>

<p>The request includes a URL identifying the affected resource, a method that defines the required action (for example to get, delete, or post the resource), and may include additional information encoded in URL parameters (the field-value pairs sent via a <a href="https://en.wikipedia.org/wiki/Query_string" rel="noreferrer">query string</a>), as POST data (data sent by the <a href="/en-US/docs/Web/HTTP/Methods/POST" rel="noreferrer">HTTP POST method</a>), or in associated {{glossary("Cookie", "cookies")}}.</p>

<p>Web servers wait for client request messages, process them when they arrive, and reply to the web browser with an <strong>HTTP response</strong> message. The response contains a status line indicating whether or not the request succeeded (e.g. "HTTP/1.1 200 OK" for success). </p>

<p>The body of a successful response to a request would contain the requested resource (e.g. a new HTML page, or an image, etc...), which could then be displayed by the web browser.</p>

<h3 id="Static_sites">Static sites</h3>

<p>The diagram below shows a basic web server architecture for a <em>static site</em> (a static site is one that returns the same hard-coded content from the server whenever a particular resource is requested). When a user wants to navigate to a page, the browser sends an HTTP "GET" request specifying its URL.</p>

<p>The server retrieves the requested document from its file system and returns an HTTP response containing the document and a <a href="/en-US/docs/Web/HTTP/Status#Successful_responses" rel="noreferrer">success status</a> (usually 200 OK). If the file cannot be retrieved for some reason, an error status is returned (see <a href="/en-US/docs/Web/HTTP/Status#Client_error_responses" rel="noreferrer">client error responses</a> and <a href="/en-US/docs/Web/HTTP/Status#Server_error_responses" rel="noreferrer">server error responses</a>).</p>

<p><img alt="A simplified diagram of a static web server." src="https://mdn.mozillademos.org/files/13841/Basic%20Static%20App%20Server.png" style="height: 223px; width: 800px;"></p>

<h3 id="Dynamic_sites">Dynamic sites</h3>

<p>A dynamic website is one where some of the response content is generated <em>dynamically </em>only when needed. On a dynamic website HTML pages are normally created by inserting data from a database into placeholders in HTML templates (this is a much more efficient way of storing large amounts of content than using static websites). </p>

<p>A dynamic site can return different data for a URL based on information provided by the user or stored preferences and can perform other operations as part of returning a response (e.g. sending notifications).</p>

<p>Most of the code to support a dynamic website must run on the server. Creating this code is known as "<strong>server-side programming</strong>" (or sometimes "<strong>back-end scripting</strong>").</p>

<p>The diagram below shows a simple architecture for a <em>dynamic website</em>. As in the previous diagram, browsers send HTTP requests to the server, then the server processes the requests and returns appropriate HTTP responses.</p>

<p>Requests for <em>static </em>resources are handled in the same way as for static sites (static resources are any files that don't change —typically: CSS, JavaScript, Images, pre-created PDF files etc). </p>

<p><img alt="A simplified diagram of a web server that uses server-side programming to get information from a database and construct HTML from templates. This is the same diagram as is in the Client-Server overview." src="https://mdn.mozillademos.org/files/13839/Web%20Application%20with%20HTML%20and%20Steps.png"></p>

<p>Requests for dynamic resources are instead forwarded (2) to server-side code (shown in the diagram as a <em>Web Application</em>). For "dynamic requests" the server interprets the request, reads required information from the database (3), combines the retrieved data with HTML templates (4), and sends back a response containing the generated HTML (5,6). </p>

<div>
<h2 id="Are_server-side_and_client-side_programming_the_same">Are server-side and client-side programming the same?</h2>
</div>

<p>Let's now turn our attention to the code involved in server-side and client-side programming. In each case, the code is significantly different:</p>

<ul>
 <li>They have different purposes and concerns.</li>
 <li>They generally don't use the same programming languages (the exception being JavaScript, which can be used on the server- and client-side).</li>
 <li>They run inside different operating system environments.</li>
</ul>

<p>Code running in the browser is known as <strong>client-side code </strong>and is primarily concerned with improving the appearance and behavior of a rendered web page. This includes selecting and styling UI components, creating layouts, navigation, form validation, etc. By contrast, server-side website programming mostly involves choosing <em>which content</em> is returned to the browser in response to requests. The server-side code handles tasks like validating submitted data and requests, using databases to store and retrieve data and sending the correct data to the client as required.</p>

<p>Client-side code is written using <a href="/en-US/docs/Learn/HTML" rel="noreferrer">HTML</a><a href="/en-US/docs/Learn/CSS" rel="noreferrer">CSS</a>, and <a href="/en-US/docs/Learn/JavaScript" rel="noreferrer">JavaScript</a> — it is run inside a web browser and has little or no access to the underlying operating system (including limited access to the file system).</p>

<p>Web developers can't control what browser every user might be using to view a website  — browsers provide inconsistent levels of compatibility with client-side code features, and part of the challenge of client-side programming is handling differences in browser support gracefully.</p>

<p>Server-side code can be written in any number of programming languages — examples of popular server-side web languages include PHP, Python, Ruby, C#, and NodeJS(JavaScript). The server-side code has full access to the server operating system and the developer can choose what programming language (and specific version) they wish to use.</p>

<p>Developers typically write their code using <strong>web frameworks</strong>. Web frameworks are collections of functions, objects, rules and other code constructs designed to solve common problems, speed up development, and simplify the different types of tasks faced in a particular domain.</p>

<p>Again, while both client and server-side code use frameworks, the domains are very different, and hence so are the frameworks. Client-side web frameworks simplify layout and presentation tasks while server-side web frameworks provide a lot of “common” web server functionality that you might otherwise have to implement yourself (e.g. support for sessions, support for users and authentication, easy database access, templating libraries, etc.).</p>

<div class="note">
<p><strong>Note</strong>: Client-side frameworks are often used to help speed up development of client-side code, but you can also choose to write all the code by hand; in fact, writing your code by hand can be quicker and more efficient if you only need a small, simple web site UI.</p>

<p>In contrast, you would almost never consider writing the server-side component of a web app without a framework — implementing a vital feature like an HTTP server is really hard to do from scratch in say Python, but Python web frameworks like Django provide one out of the box, along with other very useful tools.</p>
</div>

<div>
<h2 id="What_can_you_do_on_the_server-side">What can you do on the server-side?</h2>

<p>Server-side programming is very useful because it allows us to <em>efficiently</em> deliver information tailored for individual users and thereby create a much better user experience.</p>
</div>

<p>Companies like Amazon use server-side programming to construct search results for products, make targeted product suggestions based on client preferences and previous buying habits, simplify purchases, etc.</p>

<p>Banks use server-side programming to store account information and allow only authorized users to view and make transactions. Other services like Facebook, Twitter, Instagram, and Wikipedia use server-side programming to highlight, share, and control access to interesting content.</p>

<p>Some of the common uses and benefits of server-side programming are listed below. You'll note that there is some overlap!</p>

<h3 id="Efficient_storage_and_delivery_of_information">Efficient storage and delivery of information</h3>

<p>Imagine how many products are available on Amazon, and imagine how many posts have been written on Facebook? Creating a separate static page for each product or post would be completely impractical.</p>

<p>Server-side programming allows us to instead store the information in a database and dynamically construct and return HTML and other types of files (e.g. PDFs, images, etc.). It is also possible to simply return data ({{glossary("JSON")}}, {{glossary("XML")}}, etc.) for rendering by appropriate client-side web frameworks (this reduces the processing burden on the server and the amount of data that needs to be sent).</p>

<p>The server is not limited to sending information from databases, and might alternatively return the result of software tools, or data from communications services. The content can even be targeted for the type of client device that is receiving it.</p>

<p>Because the information is in a database, it can also more easily be shared and updated with other business systems (for example, when products are sold either online or in a shop, the shop might update its database of inventory).</p>

<div class="note">
<p><strong>Note</strong>: Your imagination doesn't have to work hard to see the benefit of server-side code for efficient storage and delivery of information:</p>

<ol>
 <li>Go to <a href="https://www.amazon.com" rel="noreferrer">Amazon</a> or some other e-commerce site.</li>
 <li>Search for a number of keywords and note how the page structure doesn't change, even though the results do. </li>
 <li>Open two or three different products. Note again how they have a common structure and layout, but the content for different products has been pulled from the database.</li>
</ol>

<p>For a common search term ("fish", say) you can see literally millions of returned values. Using a database allows these to be stored and shared efficiently, and it allows the presentation of the information to be controlled in just one place.</p>
</div>

<h3 id="Customised_user_experience">Customised user experience</h3>

<p>Servers can store and use information about clients to provide a convenient and tailored user experience. For example, many sites store credit cards so that details don't have to be entered again. Sites like Google Maps can use saved or current locations for providing routing information, and search or travel history to highlight local businesses in search results.</p>

<p>A deeper analysis of user habits can be used to anticipate their interests and further customize responses and notifications, for example providing a list of previously visited or popular locations you may want to look at on a map.</p>

<div class="note">
<p><strong>Note: </strong><a href="https://maps.google.com/" rel="noreferrer">Google Maps</a> saves your search and visit history. Frequently visited or frequently searched locations are highlighted more than others.</p>

<p>Google search results are optimized based on previous searches.</p>

<ol>
 <li> Go to <a href="https:\\google.com" rel="noreferrer">Google search</a>.</li>
 <li> Search for "football".</li>
 <li> Now try typing "favourite" in the search box and observe the autocomplete search predictions.</li>
</ol>

<p>Coincidence? Nada!</p>
</div>

<h3 id="Controlled_access_to_content">Controlled access to content</h3>

<p>Server-side programming allows sites to restrict access to authorized users and serve only the information that a user is permitted to see.</p>

<p>Real world examples include:</p>

<ul>
 <li>Social networks like Facebook allow users to fully control their own data but only allow their friends to view or comment on it. The user determines who can see their data, and by extension, whose data appears in their feed —  authorization is a central part of the user experience!</li>
 <li>
  <p>The site you are on right now controls access to content: articles are visible to everyone, but only users who have logged in can edit the content. To try this, click on the <strong>Edit </strong>button at the top of this page — if you are logged in you will be shown the edit view; if you are not logged in you will be taken to the sign-up page.</p>
 </li>
</ul>

<div class="note">
<p><strong>Note</strong>: Consider other real examples where access to content is controlled. For example, what can you see if you go to the online site for your bank? Log in to your account — what additional information can you see and modify? What information can you see that only the bank can change?</p>
</div>

<h3 id="Store_sessionstate_information">Store session/state information</h3>

<p>Server-side programming allows developers to make use of <strong>sessions</strong> — basically, a mechanism that allows a server to store information on the current user of a site and send different responses based on that information.</p>

<p>This allows, for example, a site to know that a user has previously logged in and display links to their emails or order history, or perhaps save the state of a simple game so that the user can go to a site again and carry on where they left it.</p>

<div class="note">
<p><strong>Note</strong>: Visit a newspaper site that has a subscription model and open a bunch of tabs (e.g. <a href="http://www.theage.com.au/" rel="noreferrer">The Age</a>). Continue to visit the site over a few hours/days. Eventually, you will start to be redirected to pages explaining how to subscribe, and you will be unable to access articles. This information is an example of session information stored in cookies.</p>
</div>

<h3 id="Notifications_and_communication">Notifications and communication</h3>

<p>Servers can send general or user-specific notifications through the website itself or via email, SMS, instant messaging, video conversations, or other communications services.</p>

<p>A few examples include:</p>

<ul>
 <li>Facebook and Twitter send emails and SMS messages to notify you of new communications.</li>
 <li>Amazon regularly sends product e-mails that suggest products similar to those already bought or viewed that you might be interested in.</li>
 <li>A web server might send warning messages to site administrators alerting them to low memory on the server, or suspicious user activity.</li>
</ul>

<div class="note">
<p><strong>Note</strong>: The most common type of notification is a "confirmation of registration". Pick almost any large site that you are interested in (Google, Amazon, Instagram, etc.) and create a new account using your email address. You will shortly receive an email confirming your registration, or requiring acknowledgment to activate your account.</p>
</div>

<h3 id="Data_analysis">Data analysis</h3>

<p>A website may collect a lot of data about users: what they search for, what they buy, what they recommend, how long they stay on each page. Server-side programming can be used to refine responses based on analysis of this data.</p>

<p>For example, Amazon and Google both advertise products based on previous searches (and purchases).</p>

<div class="note">
<p><strong>Note</strong>: If you're a Facebook user, go to your main feed and look at the stream of posts. Note how some of the posts are out of numerical order - in particular, posts with more "likes" are often higher on the list than more recent posts.</p>

<p>Also look at what kind of ads you are being shown — you might see ads for things you looked at on other sites. Facebook's algorithm for highlighting content and advertising can be a bit of a mystery, but it is clear that it does depend on your likes and viewing habits!</p>
</div>

<h2 id="Summary">Summary</h2>

<p>Congratulations, you've reached the end of the first article about server-side programming. </p>

<p>You've now learned that server-side code is run on a web server and that its main role is to control <em>what</em> information is sent to the user (while client-side code mainly handles the structure and presentation of that data to the user).</p>

<p>You should also understand that it is useful because it allows us to create websites that <em>efficiently</em> deliver information tailored for individual users and have a good idea of some of the things you might be able to do when you're a server-side programmer.</p>

<p>Lastly, you should understand that server-side code can be written in a number of programming languages and that you should use a web framework to make the whole process easier. </p>

<p>In a future article we'll help you choose the best web framework for your first site; Next, though we'll take you through the main client-server interactions in just a little more detail.</p>

<p>{{NextMenu("Learn/Server-side/First_steps/Client-Server_overview", "Learn/Server-side/First_steps")}}</p>

<h2 id="In_this_module">In this module</h2>

<ul>
 <li><a href="/en-US/docs/Learn/Server-side/First_steps/Introduction" rel="noreferrer">Introduction to the server side</a></li>
 <li><a href="/en-US/docs/Learn/Server-side/First_steps/Client-Server_overview" rel="noreferrer">Client-Server overview</a></li>
 <li><a href="/en-US/docs/Learn/Server-side/First_steps/Web_frameworks" rel="noreferrer">Server-side web frameworks</a></li>
 <li><a href="/en-US/docs/Learn/Server-side/First_steps/Website_security" rel="noreferrer">Website security</a></li>
</ul>