Webapps - Revision history

Admin: /* Building an API */

2017-08-21T01:09:07Z

Building an API

← Older revision		Revision as of 01:09, 21 August 2017
Line 153:		Line 153:
	==Building an API==		==Building an API==

	While entire books have been written on the subject of how to write an API, I'm only going to cover some embarrassingly simple APIs~~. You can think very deeply about how to translate a web app workflow into nouns, verbs, and adjectives, and how to translate those into a useful API. But this will be very simple~~.		While entire books have been written on the subject of how to write an API, I'm only going to cover some embarrassingly simple APIs.

	I use Python Flask to build APIs.		I use Python Flask to build APIs.

	~~API REST requests~~		See [[Flask]] page.



	[[Category:Javascript]]		[[Category:Javascript]]
	[[Category:Python]]		[[Category:Python]]
	~~[[Category:HTTP]]~~
	[[Category:Webapps]]		[[Category:Webapps]]

Admin: /* Building an API */

2017-08-21T01:08:28Z

Building an API

← Older revision		Revision as of 01:08, 21 August 2017
Line 161:		Line 161:
	[[Category:Javascript]]		[[Category:Javascript]]
	[[Category:Python]]		[[Category:Python]]
			[[Category:HTTP]]
			[[Category:Webapps]]

Admin: /* POST JSON */

2015-07-27T22:51:20Z

POST JSON

← Older revision		Revision as of 22:51, 27 July 2015
Line 122:		Line 122:


			=APIs=

			While it's possible to implement GET and POST requests in a webapp, sometimes you want the best of both worlds. It isn't always convenient to wrap a bunch of functionality into the right function calls for the right POST request with the right headers.

			You want something easy. Something simple. Something like:

			<pre>
			http://charlesreid1.com/data/get/my_favorite_dataset
			</pre>

			and in a perfect world, this would translate into a command to the server: "I need something from a data set! I need to get a dataset! I need to get my_favorite_dataset!" We could incorporate this into a web app a number of different ways. One way would be to turn actions (like, go to the next map page) into database requests ("I need something from a map dataset! I need page 15!"). Another way would be to make the components of a webapp itself available at different URLs, so that as the user proceeds through the web app and makes different choices, they are guided along different routes with different URL paths.

			In fact, we can do all of this!

			This type of API, using a URL to make requests, is called a RESTful API (or sometimes a SOAP API). This just means that we're turning a request for a webpage into a request for some generic resource.

			And while this makes it easier for us to use on the front end, the real power comes from the back end. We can use Python to link a particular URL request to chunks of Python code. This means, anything we can do with Python, we can do with a REST API! That's huuuuge!

			==The API Front End==

			We talked about the API front end: it basically consists of URLs that the user requests. How this looks in practice depends on how you've implemented the API. But most of the time, you aren't building the API URLs for users to access directly. Most of the time, if a computer requests that URL, the server will return something that isn't human-readable, like JSON or XML.



			==The API Back End==




			==Building an API==

			While entire books have been written on the subject of how to write an API, I'm only going to cover some embarrassingly simple APIs. You can think very deeply about how to translate a web app workflow into nouns, verbs, and adjectives, and how to translate those into a useful API. But this will be very simple.

			I use Python Flask to build APIs.

			API REST requests

	[[Category:Javascript]]		[[Category:Javascript]]
	[[Category:Python]]		[[Category:Python]]

Admin: /* Servers and Clients */

2015-07-27T22:34:15Z

Servers and Clients

@@ Line 62: / Line 62: @@
 If we are drawing data from a large database on the server side, the data that is initially sent is just a small, initial bundle of data - like the first place you see when you open Google Maps. As the client interacts with the map, and requests different information, that Javascript code will ask the server for additional data.
 [[Category:Javascript]]
 [[Category:Python]]

Admin: /* A Simple Example */

2015-07-27T02:28:27Z

A Simple Example

← Older revision		Revision as of 02:28, 27 July 2015
Line 38:		Line 38:

	Open this webapp in a new window: http://charlesreid1.github.io/a-shrubbery/educationca/		Open this webapp in a new window: http://charlesreid1.github.io/a-shrubbery/educationca/

			You'll see something like this:

			[[Image:ExampleWebapp.png\|700px]]

	This is a simple client-side web app that visualizes map-related data. It is hosted on GitHub pages, which means that the server, in this case, is a server at GitHub's data center. The client is you - or, more specifically, your browser.		This is a simple client-side web app that visualizes map-related data. It is hosted on GitHub pages, which means that the server, in this case, is a server at GitHub's data center. The client is you - or, more specifically, your browser.

Admin: /* A Simple Example */

2015-07-27T02:26:45Z

A Simple Example

← Older revision		Revision as of 02:26, 27 July 2015
Line 49:		Line 49:
	When we request a Javascript web app, the process looks exactly the same, except now the returned page includes a bundle of Javascript code, which the browser will execute in addition to displaying the HTML.		When we request a Javascript web app, the process looks exactly the same, except now the returned page includes a bundle of Javascript code, which the browser will execute in addition to displaying the HTML.

			Let's take a look at what the server is sending the client.

			[[Image:Webapp_4_javascript.jpg\|700px]]

			Here, we take a peek into what the server is sending as a response, and we can see HTML and Javascript files. These are executed by the browser to create the web app for the user.

			The main HTML page contains the necessary material for a webpage: the white background, the header, the navigation bar, etc. The dynamic web app in our Javascript file provides the code for the web app. It references several other files, such as a file with Javascript code for drawing data on a map, and a file with Javascript code for drawing charts displaying map data. These, in turn, refer to other Javascript files, or to data files. The server sends along everything that the web app specifies is needed for the initial request.

			If we are drawing data from a large database on the server side, the data that is initially sent is just a small, initial bundle of data - like the first place you see when you open Google Maps. As the client interacts with the map, and requests different information, that Javascript code will ask the server for additional data.

Admin: /* A Simple Example */

2015-07-27T01:57:38Z

A Simple Example

← Older revision		Revision as of 01:57, 27 July 2015
Line 46:		Line 46:

	[[Image:Webapp_3_html.jpg\|700px]]		[[Image:Webapp_3_html.jpg\|700px]]

			When we request a Javascript web app, the process looks exactly the same, except now the returned page includes a bundle of Javascript code, which the browser will execute in addition to displaying the HTML.

Admin: /* The Clients */

2015-07-27T01:50:55Z

The Clients

← Older revision		Revision as of 01:50, 27 July 2015
Line 33:		Line 33:
	[[Image:Webapp_jspy.jpg\|700px]]		[[Image:Webapp_jspy.jpg\|700px]]

	=The ~~Clients=~~		==A Simple Example==

			Let's make all this abstract stuff a little more concrete with a simple example.

			Open this webapp in a new window: http://charlesreid1.github.io/a-shrubbery/educationca/

			This is a simple client-side web app that visualizes map-related data. It is hosted on GitHub pages, which means that the server, in this case, is a server at GitHub's data center. The client is you - or, more specifically, your browser.

			When you open a regular HTML website in your browser, your browser sends a request for that page to the server (the protocol for that request is HTTP). The server sees the request, and returns the HTML for that page to your browser, which then renders it and shows it to you.

			When you open a web app that has client-side Javascript in your browser, your browser sends a request to the server, as before. The server returns the HTML for that page, plus the Javascript code to execute. That HTML is rendered, and that Javascript is executed, and the end result is a client-side, dynamic website.

			[[Image:Webapp_3_html.jpg\|700px]]

	~~Normally,~~

Admin: /* Servers and Clients */

2015-07-27T00:54:10Z

Servers and Clients

← Older revision		Revision as of 00:54, 27 July 2015
Line 33:		Line 33:
	[[Image:Webapp_jspy.jpg\|700px]]		[[Image:Webapp_jspy.jpg\|700px]]

			=The Clients=

			Normally,

Admin: /* Python vs Javscript */

2015-07-27T00:49:22Z

Python vs Javscript

← Older revision		Revision as of 00:49, 27 July 2015
Line 29:		Line 29:
	We've seen that the main concern when designing a web app is location: client or remote side. This also has implications for the languages that we can use.		We've seen that the main concern when designing a web app is location: client or remote side. This also has implications for the languages that we can use.

	Javascript is designed as a client-side language, since it runs in the browser (although it can be hacked so you can use it as a server side language). Python, on the other hand, does not run in the browser, so it lacks the portability of Javascript. But Python has enormous power and an amazing selection of libraries, making it a great do-anything ~~library~~:		Javascript is designed as a client-side language, since it runs in the browser (although it can be hacked so you can use it as a server side language). Python, on the other hand, does not run in the browser, so it lacks the portability of Javascript. But Python has enormous power and an amazing selection of libraries, making it a great do-anything language:

	[[Image:Webapp_jspy.jpg\|700px]]		[[Image:Webapp_jspy.jpg\|700px]]