WebFund 2016W Lecture 24

From Soma-notes
Revision as of 22:50, 7 April 2016 by Soma (talk | contribs) (Created page with "==Video== The video for the lecture given on April 7, 2016 [http://homeostasis.scs.carleton.ca/~soma/webfund-2016w/lectures/comp2406-2016w-lec24-07Apr2016.mp4 is now availabl...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Video

The video for the lecture given on April 7, 2016 is now available.

Notes

In Class

Lecture 24
----------

Modern web pages are a mess because they draw content
(and code) from many sources
* Including that content is easy, you just make a few
  changes, typically saying to load some JavaScript

Is there any barrier between that external code
and your client-side code?
* not really
* there are technologies for separating content, and
* JavaScript provides some separation (e.g. lexical scoping)
* But everyone shares the DOM

So if you control any of the content in a page,
you can potentially change any of it
* Imagine censoring comments


If you want others to incorporate your stuff into their
pages, what do you offer?

Maybe offer some sort of API...but how?

Maybe just give a link to my animated GIFs?
 - but a link to which one?
 - random every time?

Why not just give them JSON + JavaScript?
* Just give JavaScript, it will load the JSON on its own

So when anyone talks about "Web Services"
* Make an API out of HTTP requests (GET, POST, ...)

Might be accessed by
* a web page from the developer
* 3rd party web page
* mobile apps
* any other program connected to the Internet

It doesn't matter to the server.
THIS is the key benefit of a "RESTful" API

Used to be 2 ways to do a "Web Service":
* REST (e.g., use regular HTTP GET and POST)
* SOAP


(at least) Two schools of thought for code talking to
code:
* make everything a function call
* do something weird for network communication

SOAP is just a way to do function calls over HTTP

How do you do a function call over HTTP?
 - prepare arguments
 - send arguments
 - invoke remote function
 - retrieve result
 - store result

What about
* types?
  - have to communicate that
* but think how complicated data structures can get
* Solution: XML Schemas for data

SOAP is an example of RPC: remote procedure calls
but over HTTP

RPC turns local code into network code, but
local code isn't ready to face the network
 * security
 * efficiency

So why SOAP?
 * the old ways of doing RPC were blocked by firewalls

There's a "winpopup" service in Windows
 * pops up a window
 * as requested by a remote host

REST came along when "web natives" (programmers)
realized they didn't need all that infrastructure

Easy to see new things as "mostly old things"
But really you need to see it as its own thing
to really master it

What is the web?

* Publishing
* e-commerce (mail order catalogs)
* Information access (fine-grained)
* Multimedia
  - realplayer => youtube
  - CDs and videos
* VoIP (telephony), telegrams


* Social media
  - gossip

* "Uberization"
  - use a mobile app to connect people for business
 
Some of the progress in web technologies today is to
make "platforms"

Platforms are really technology looking for a purpose

Weird thing about the web is it is a "platform" that
nobody controls
 * Good: allows innovation
 * Bad: evolutionary cruft

Programmers HATE evolutionary cruft
 - it doesn't make sense!
 - its a mess!


Many, many investors don't like the web as a platform
 - they want to control the platform

iOS as a platform
 * apple gets 30%

Google takes a cut from the Play store as well

Platforms are a play at a monopoly in a space

Two directions