Let me say write off that I do not pay for my own ticket to QCON, my boss picks up the tag. I love QCON. It is definitely not MIX. I go there to see what is happening in the world which is NOT Oracle and Not Microsoft. That’s the same reason I read their online Zine: InfoQ. QCon always provides a look at what is current and recent in the open stack world. This year we looked closely at REST, Mobile development, Web API and NOSQL. As they did last year QCON provides a nice look at what is open and emerging. Big metal with always be with us but the desk top is looking very weak during the next few years while Mobile devices of all kinds and makers are exploding. The biggest fall out is that while HTML5 is only slowly emerging on desktops in place, all new Mobile devices (which is to say most new systems) will be fully HTML5 compliant. Not only that but with the exception of Windows Phones, the rendering engine for all mobile devices is based on WebKit. What this mean for those of us in the cubes is that worrying about how to bridge to pre-HTML5 browsers with HTML5 code is a non-issue. Mobile development is HTML5 development. The big metal end of the supply chain is being segmented into Web API servers (which service JSON XHR2 data calls) and the NOSQL engines which serve the WEB API farms. Remember a native mobile app ideally has pre-loaded all of its pages its interactions are solely over JSON XHR2 for data (be it documents, data or HTML fragments). The traditional JSP or ASPX web server is not really in play with native mobile apps and has and increasingly small role to play in “native like” or browser based mobile apps. Let’s move on.
“IPad Light by cloud2013”
Speaking of moving on: There is an occupation going on in this country. I visited occupations sites in San Francisco, UCal Berkeley and Berkeley “Tent City”. These are all very active and inspiring occupy sites. Now if we can only get to Occupy Silicon Valley!
Workshop: REST In Practice by the Authors: Ian Robinson & Jim Webber
Why REST? The claims:
· Fault Tolerant
Do we agree with these goals?
Does REST achieve them?
Are there other ways to achieve the same goals?
REST design is important for serving AJAX requests and AJAX requests are becoming central to Mobile device development, as opposed to intra-corporate communication. See Web API section below.
Occupy Market Street (San Francisco)
The new basic Document for REST: Richardson Maturity Model (with DLR modifications)
One URI endpoint
One HTTP method [Get]
One HTTP Method [Get]
Century Level HTTP Codes (200,300,400,500)
Multiple HTTP Methods
Fine Grain HTTP Codes (“Any code below 500 is not an error, it’s an event”)
Media Format Negotiation (Accept request-header)
Headers become major players in the interaction between client and server
Level 3: The Semantic Web
Level 2 plus
Links and Forms Tags (Hypermedia as the engine of state)
Plus emergent semantics
<link rel=”self” href=http://restbucks.com/quotes/1234 type=”application/restbucks+xml”/>
<link rel=”rb:order-form” href=”http://restbucks.com/order-forms/1234″ type=”application/restbucks+xml”/>
Think of the browser (user) as a finite State Machine where the workflow is driven by link tags which direct the client as to which states it may transition to and the URI associated with each state transition.
The classic design paper on applied REST architecture is here: How To GET a Cup Of Coffee. Moving beyond level 1 requires fine grain usage of HTTP Status Codes, Link tags, the change headers and media type negotiation. Media formats beyond POX and JSON are required to use level 3 efficiently (OData and ATOM.PUB for example).
Dude, where’s my two phase commit? Not supported directly, use the change headers (if-modified, if-non-match, etag headers) or architectural redesign (redefine resources or workflow). Strategic choice is design of the finite state machine and defining resource granularity.
(Slide from Rest in Practice)
The Bad Old Days: One resource many, many ‘verbs’.
The Happy Future: Many, many resources, few verbs.
The Hand Cuff Era: Few Resources, Few verbs.
The Greater Verbs:
GET: Retrieve a representation of a resource
POST: Create a new resource (Server sets the key)
PUT: Create new resource (Client sets the key); ( or Update an existing resource ?)
DELETE: Delete an existing resource
Comment: The proper use of PUT vs. POST is still subject to controversy and indicates (to me) that level 3 is still not well defined.
Typically they say POST to create a blog entry and PUT at append a comment to a blog. In Couchdb we POST to create a document and PUT to add a revision (not a delta) and get back a new version number. The difference here is how the resource is being defined, which is an architectural choice.
The Lesser Verbs:
OPTIONS: See which verbs a resource understands
HEAD: Return only the header (no response body)
PATCH: Does not exist in HTML5. This would be a delta Verb but no one could agree on a specification for the content. Microsoft did some early work on this with their XML Diffgram but no one else followed suit.
Authentication (in order of increased security)
Basic Auth + SSL
WSSE Authentication (ATOM uses this)
Message Level Encrypt (WS-SEC)
For the Microsoft coders I highly recommend
RESTful .Net (WCF For REST (Framework 3.5) Jon Flanders
There are significant advantages to building your RESTful services using .Net. Here is a comparison table to get you oriented:
|Web Service Standard||REST Service||WCF For REST (Framework 3.5)|
|1||TCP/IP + others||TCP/IP||TCP/IP|
|3||SOAP Headers||HTTP Headers||HTTP Headers|
|4||WS*Security||Basic Auth/SSL||Basic Auth/SSL or WS*Security|
|5||Early Binding||Late Binding||Late Binding|
|7||XML||Media Negotiation||Media Negotiation|
|8||SOAP FAULTS||HTTP Response Codes||HTTP Response Codes|
|9||Single Endpoint||Multiple Endpoints, URI Templates||Multiple Endpoints, URI Templates|
The REST of the Week
Wednesday is more or less vendor day at QCON and the sessions are a step down from the tutorials but the session quality picked up again on Thursday and Friday. XXX XXXX who gave an excellent tutorial last year gave an informative talk on ‘good code’. The Mobile Development and HTML5 tracks were well attended and quite informative. The fie ld is wild open with many supporting systems being free to the developer (support will cost you extra) and the choices are broad: from browser ‘responsive design’ application to native appearing applications to native apps ( and someone threw in “hybrid app” into the mix). The Mobile panel of IBM DOJO, JQuery.Mobil and Sencha was hot. I am new (to say the least) to Mobile development but here are my (somewhat) random notes on these sessions:
MOBILE Development is HTML5 Development
HTML5 is the stack. Phone and Tablet applications use WebKit based rendering engines and HTML5 conformant browsers only (Windows Phone 7 is the exception here). HTML5 has its own new security concerns ( New Security Concerns)
Three major application development approaches are:
· Browser Applications;
· Native like Applications;
· Hybrid Applications; and
· Native Applications.
Browser applications may emulate the screens seen on the parallel desk top browser versions on the front end but in practice the major players (Facebook, YouTube, Gmail) make substantial modifications to at least the non-visual parts of the Mobile experience making extensive use of local storage and the HTML5 manifest standard for performance and to allow for a reasonable off line experience. Browser applications fall under the guidelines of Responsive Design (aka adaptive Design) and tend to be used when content will appear similarly between desktop and Mobile devices.
“Native like” applications use:
· The Browser in full screen Mode with no browser ‘chrome’; and
· Widgets are created using CSS, JS and HTML5 which simulate the ‘look and feel’ of a native application;
A Native application is still an HTML5 application with the following characteristics:
· All JS Libraries, CSS and HTML are packaged and pre-loaded using a vendor specific MSI/Setup package;
· AJAX type calls for data are allowed;
· Access to Native Widgets and/or Widgets are created using CSS, JS and HTML5
· Access to Native Functionality (GPS, Camera, etc)
· Standard HTTP GET or POST are NOT allowed
AJAX calls are made via XHR2 (aka XMLHttpRequest Level 2) which among other things relaxes the single domain requirement of XHR and processing Blob and File interfaces.
The following major vendors offer free libraries and IDE for development:
Native Apps: PhoneGap, Appcelerator
Browser App: JQuery.Mobile
PhoneGap does NOT require replacement of Sencha, JQuery.Mobil, Dojo.Mobile JQuery libraries.
Sencha does not require replacement of the JQuery.Mobil, Dojo.Mobile JQuery libraries.
This is a major area of performance efforts and is still very much open in terms of how best to approach the problem:
The major elements are:
App Cache (for pre-fetch. and Native App Approach)
DOM Storage (aka Web Storage)
IndexedDB (vs. Web SQL)
File API (this is really part of XHR2)
Storing Large Amounts of Data Locally
If you are looking to store many Megabytes – or more, beware that there are limits in place, which are handled in different ways depending on the browser and the particular API we’re talking about. In most cases, there is a magic number of 5MB. For Application Cache and the various offline stores, there will be no problem if your domain stores under 5MB. When you go above that, various things can happen: (a) it won’t work; (b) the browser will request the user for more space; (c) the browser will check for special configuration (as with the “unlimited_storage” permission in the Chrome extension manifest).
Storage Non-Support as of two weeks ago.
|IndexedDB||Supported||Supported||No Support||Supported||No Support||No Support||No Support|
|WEB SQL||No Support||Supported||Supported||No Support||Supported||Supported||Supported|
What is it? Just a name for breaking out the AJAX servers from the web server. This is an expansion of REST into just serving data for XHR. It is a helpful way to specialize our design discussions by separating serving pages (with MVC or whatever) from serving data calls from the web page. Except for security the two can be architecturally separated.
Web APIs Technology Stack
Look familiarr? Looks like our old web server stack to me.
- Consistency: (all nodes have the same data at the same time)
- Availability: (every request receives a response – no timeouts, offline)
- Partition tolerance: (the system continues to operate despite arbitrary message loss)
If some of the data you are serving can tolerate Eventual Consistency then NOSQL is much faster.
If you need two phase commit, either use a SQL database OR redefine your resource to eliminate the need for the 2Phase Commit.
NoSQL databases come in two basic flavors:
Key/Value: This are popular with content management and where response time must be minimal. In general you define what btrees you want to use before the fact. There are no on the fly Joins or projects. MongoDB and CouchDB are typical leaders in this area.
Photos: All Photos by Cloud2013