Merge pull request #3 from gudmundurste12/master

gudmundurste12 #1

Week01/1. Web Services.md

@@ -2,17 +2,17 @@
 
 ## Historical background
 
-Traditional web applications (ASP, PHP, ASP.NET WebForms/MVC, Ruby on Rails etc.) are usually applications where everything is rendered server-side, and the client (i.e. the web browser) receives an HTML document. This has architecture has a number of pros:
+Traditional web applications (ASP, PHP, ASP.NET WebForms/MVC, Ruby on Rails etc.) are usually applications where everything is rendered server-side, and the client (i.e. the web browser) receives an HTML document. This architecture has a number of pros:
 
 * the client can be "lightweight", i.e. it only has to render the HTML
 * if the application has to be modified, it can be done in a single place, i.e. on the server
 
 However, there are also cons:
 
 * this may result in a lot of overhead being passed between client and server, i.e. a small change in a page may result in a full page reload
-* if the client isn't a web browser, it will have to parse the result and extract exactly the data it needs to display, this is fragile and error-prone.
+* if the client isn't a web browser, it will have to parse the result and extract exactly the data it needs to display, which is fragile and error-prone.
 
-In recent years, a different architecture has become increasingly popular: the server doesn't render a full HTML page, but only delivers the data. The client must then take care of render the data, usually as HTML, but other clients (i.e. iOS/Android apps) can use different rendering methods.
+In recent years, a different architecture has become increasingly popular: the server doesn't render a full HTML page, but only delivers the data. The client must then take care of rendering the data, usually as HTML, but other clients (i.e. iOS/Android apps) can use different rendering methods.
 
 In general, having an API is the most important decision you can make. How it is implemented is less important.