05 web services
TRANSCRIPT
Architect: Web Email ClientEntirely Web Based Email Client Application
Loading the application displays the inbox
Clicking on any of the messages displays the content of the message
Clicking a folder displays the contents of the folder
Clicking the compose button displays a modal window to write a new email
Web APIs
Application Programming Interface (API).
Can use any data format—normally JSON is preferred.
Aim to provide data to Applications, rather than full web-pages.
Should use HTTP Verbs Semantically
gettingContent = $.getJSON(url);gettingContent.done(function (data) { console.log(1); }); !
console.log(2);
Same-origin policy
Enforced by all major browsers
Prevents AJAX calls from being made to other domains
Web apps can’t (by default) call APIs on another domain
Cross Origin Resource SharingJavascript (example1.com) makes request to API (example2.com)
Browser includes origin header stating where the JS is from
Origin: http://www.example1.com
API decides http://www.example1.com is OK
Response includes Access-Control-Allow-Origin header
Access-Control-Allow-Origin: http://www.example1.com
Browser allows request to finish when it sees the allow header
CORS Pitfalls
Recent addition to HTTP spec
All [new] API’s should support it, but don’t expect browser’s to
CORS is the way of the future and the proper way to share resources, but still to unreliable.
JSON with Padding (JSONP)
Exploits a loop-hole in browser security
Supported by all browsers and is commonly used.
Plan on using only as a patch until CORS support is better.
Only supports making GET requests
JSONPBrowser creates script tag with API Resource as src
<script src=”http://www.jw.org/01001001?callback=abcdef”></script>
Browsers have no problem with this
Server responds with JSON wrapped in a function call.abcdef({“hello”: “world”});
Browser executes code, resulting in function call with object passed as a param.
jQuery’s $.getJSON does this automatically by adding callback=? to the URL
HTTP Verbs
Describe the what the client is attempting to accomplish with the request.
Basic Verbs: GET, POST, HEAD
Recently Added: PUT, PATCH, DELETE
Idempotent [adjective] Describes an operation that can be applied multiple times without changing the result beyond the initial application.
i = 0 !
f (x) -> x + (i + 1);
>>> f(1)2>>> f(1)2>>> f(1)2
i = 0 !
f (x) -> x + (++i);
>>> f(1)2>>> f(1)3>>> f(1)4
GET: Request data from the server. Request is read-only and idempotent.
POST: Save data from the client to the server. Request involves a write and is not idempotent.
HEAD: Same as GET, but only return the HTTP Headers.
PUT: Replace existing data with data from the client. Request involves writes, but is idempotent.
PATCH: Replace part of the existing data with data from the client. Request involves writes, but is idempotent.
DELETE: Delete the specified data. Request involves writes, but is idempotent.
Request the body of an email from the server
Send a new email
Delete an email
Save a new message draft
Update an existing message draft
Move an email to a new folder
Which verb would be correct?
jw.org Bible APIEditions EndpointGET http://www.jw.org/en/publications/bible/json/ Lists available Bible Editions and Languages Contains english and vernacular language names Contains links to Books Endpoint!Books EndpointGET http://www.jw.org/en/publications/bible/nwt/books/json/ Lists available books in the given language/edition!Verse Range EndpointGET http://www.jw.org/en/publications/bible/nwt/books/json/html/01001001 Returns rendered verse range Verse ID is 8 digits: <booknum><chapterNum><verseNum> Supports ranges with: <VerseID>-<VerseID>
New Requirements
Add selects for:
Editions within a language
Books and chapters within an edition
All select filters should automatically update other select boxes’ values