Ah yes... a little author-publish-consume love from to start this session...

REST 101 with Keyur Shah

It's all about addressable resources - Urls point to resources. We use use standard HTTP Verbs - GET, POST etc.

Self-descriptive messages - all necessary state is sent each time. Server then returns the complete answer.

Hiearchy of services defined as a url - catalog/service/map/layer etc

Upside of using Url for everything is that it's bookmarkable - think

"Browser is the new command line"

Lots of thought went into the Uri design - very easy to understand and explore. From my poking around, I'd agree.

"ETags" - conditional GETs - allows the client to ask the server if a repeated request for the same content is still valid. They also cache content in the REST server itself, so we should see very good performance.

gzip content done based on the browser. 70-75% content savings when combined with JSON

HTTP Status codes used to indicate... status.

REST API requires client side session state. Because there is no session state on the server, it should scale much better. GETs are cachable because any request to the same Url will always be the same (ETags handle cache expiration when data changes)

The API can also be crawled so we'll start to see deep indexing via search engines.

Response Formats

multiple response format - parameter "f". Default is html which is the explorer. Also support: json, kmz, image, help, lyr (ArcMap/ArcGlobe), nmf, jsapi (load directly into the Dojo viewer), gmaps (load directly into Google Maps), ve (guess)

The "help" option is awesome as it will return context sensitive help. Very Nice!

f=json&callback=myMethod

Call the method that the json will be sent to. A shortcut.

f=pjson or f=json&pretty=true

More readable less compressed json for debugging. FireBug goodness.

f=kmz

Much better KML integration story w/o out the config needed in 9.2. Works with caches (if mercator compatible projection). Really will allow some good geoprocessing into Google Earth. Keyur also said that Geoprocessing has been improved. Will need to check this out.

Lots of caching in the REST tier. Performance looks good, but obviously this is predicated on sensible service design - don't let your users return 10,000 features.

Ran out of juice, but the rest of the session was awesome. Yahoo Pipes demo mashing up different streams, Google Earth "application" demo. 

The REST API can serve tile caches (assuming they are in "web mercator") into Google Maps and Virtual Earth.

Commentary:

The REST API puts ESRI back in the game in terms of public facing sites and services. This is the future. From the perspective of a consultant who's prettu invested in the ESRI product line - Thanks.

Kudos to everyone who worked on this.