Jeremy Bartley and Keyur Shah (of http goodness fame) presented the first ArcGIS Server REST API session. ArcGIS Server can work with practically any client moving forward. To use the REST API, you publish your ArcGIS Server service like you’ve been doing (or reading about) for years. This means you can serve up simple maps like you would have done with ArcIMS, but also Geoprocessing services as well can be use (imagine having Google Maps work with a Geoprocessing service). The change from 9.2 is that rather than using SOAP to access the services, you can use use REST.
If you want to get into what REST is go ahead and use Google to search. The simple explanation for those who don’t have time to research search is that everything is a URL, exchange standard formats (JSON, [HTTP)] using standard verbs, and every request asks a full question and every response includes the full answer. Just think of Keyur’s "http goodness" idea. So everything is a URL. This means that your resources can be accessed via URL and thus wget, curl, JavaScript, Python, Ruby, Perl, Java and .NET. I’ll put a link here to the presentation when it gets put up on EDN and you can see the detal that Keyur explains what REST is and how it applies to ArcGIS Server (or ArcIMS ) developers
Services formats you can use are html (the Services Explorer) JSON, KMZ, image, help, Layer file that you can add to ArcMap or ArcGlobe, ArcGIS Explorer documents, jsapi, Google Maps and Virtual Earth. The Server Explorer gives developers (or nosy GIS professionals) simple and instant access to Server Level Metadata. On every Server Explorer page, you will see a link to a help file that will help you understand what is going on. JSON will be used by the JavaScript libraries (or any programming language). There is also a "pretty JSON" feature that will return a more readable JSON (f=json&pretty=true) for debugging purposes.
ArcGIS 9.3 supports KML out of the box. Therefore you can build web pages that include links to KML content. Not only does it support KML/KMZ, but it also supports query results, geocode results, Geoprocessing task results and custom raster or vector results corresponding to selected layers from a map service. So you can pass the results from analysis performed in ArcGIS Server and offer them up in your webpages for users. Rather than export a KML/KMZ out of ArcMap and linking to that on your webpage, you would just make a REST call to the KMZ format on that mxd that you published on ArcGIS Server.
REST API Admin allows developers to clear the REST API Cache that gets created. If your add, delete or updates services, you’ll want to clear the cache. You can clear the cache by clicking on a button or have it clears periodically depending on your needs. REST API Security ties in with general ArcGIS Server Security policies so you won’t have to set anything different just to use the REST API.
Jeremy demonstrated how you want to set your correct projection in your MXD file before publishing (to match Google Maps or Virtual Earth). This of course is very simple, but you want to make sure it is set correctly if you want to match the web Mercator projection. ESRI and Microsoft/Google use different cache schemes, but ESRI has a tool that will convert your tile cache from the ESRI "format" to the Microsoft/Google tile format. This is only needed for 3D as ESRI handles the conversion automatically for the 2D. One nice function is the REST API support KML regions as well.
The simplicity that you can build applications via REST is clear. If you want to run a query, all you have to do is add a url and then call the url via JavaScript. So you pass the url to the query service with the coordinates you want to query and the RESTful server will pass back the results via another url to the browser. For those who have struggled with the .NET and Java WebADFs, this simplicity will be refreshing and I think we’ll see many developers come back into the web mapping fold because they can now work with ArcGIS Server services.
Jeremy also ran a Python demo to access the ArcGIS Server services via REST. If you aren’t a .NET or Java "guy" and want to use Ruby, you can now work within your favorite language. Heck, you like Yahoo! Pipes? Just add your RESTful URLs to Pipes and run the pipe to use the Yahoo! services with your ArcGIS Server services.
The freedom to use these RESTful services where you are comfortable, or where you client requires will stop the need to "sell" the need for installing .NET or Java on a server. Any "old" http server will be able to run these applications and there is definitely no reason to be afraid of ArcGIS Server anymore. As one ArcIMS developer told me, I finally see a reason to leave AXL and move to ArcGIS Server. The REST API is well thought out, very extensive and allows access to the power of ArcGIS Server in a "simple" html page.
