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.
9 responses so far ↓
1
Matt Priour
// Mar 18, 2008 at 7:31 pm
Thanks for the info James.
And @ESRI: FINALLY!!
2
Tim Maddle
// Mar 19, 2008 at 6:21 am
Sounds incredible. I hope it work as good as it sounds.
3
Frank Hardisty
// Mar 19, 2008 at 9:14 am
I have seen some demos based on the new REST API, and I was very impressed. When I first heard about ArcServer exposing a REST API, I thought it might be mere buzzword compliance, or kind of a halfway house between REST and WS* style services. But, at least from what I saw, ESRI really stepped up to the plate and implemented REST correctly.
The downside? It’s another layer built on top of everything else, so performance is not great when writing out the RESTful resources. We may have to wait for a major revision before this changes. Of course, when *accessing* the resources, you get *better* performance, due to the built in infrastructure of the Web. That, and simplicity, are two of the major motivating factors for REST.
4
Tim Maddle
// Mar 19, 2008 at 11:37 am
Frank,
Could you explain the difference between “writing out RESTful resources” and “*accessing* the resources? ” The big question is, of course, when I do something like send a request for an image or the results of a spatial selection, does the REST implementation slow down the overall process of sending the request and getting the result?
5
ChrisW
// Mar 21, 2008 at 6:53 am
In case anyone’s interested, there’s an old-style book (you know, the paper things you can read in the bath) on REST: “RESTful Web Services” by Leonard Richardson and Sam Ruby (nominative determinism rules!) from O’Reilly. It’s a pretty thorough introduction to what REST is about and why it’s supposed to be a Good Thing. As for (non-Ruby) implementations, that looks like a whole new world of pain to this GIS/web-design newbie, especially as my funds can’t quite stretch to ArcServer…
6
tom
// Mar 21, 2008 at 10:29 am
Thanks for your information, James.
Where I can find the tool that can convert my tile cache from the ESRI “format” to the Microsoft/Google tile format?
By the way, I create a website using ArcGIS 9.3 google extesion to overly a dynamic map service with our Polygon and Point data. It works great.
7
James Fee
// Mar 21, 2008 at 10:32 am
Tom I haven’t looked in the documentation and I they didn’t demo it. Just mentioned it in the talk.
8
Geko
// Apr 2, 2008 at 9:41 am
it’s the best tecnology of map web. I work in this technology and create a map of Costa Rica the Adrees is :
http://201.198.70.66/geo/
My best regards,
Gaston Jamez
9
Alex
// Aug 4, 2008 at 1:09 pm
I just started using the REST/ArcGIS JavaScript API. Its realy very easy to use the provided functions, but is there also a way to extend the Services provided by the REST API?
i.e. i want to add a funtionality, so that the user can change the colors and neccessary values which are used to fill the polygons . Is there a way to extend the REST Services?
Thank you
Alex
Leave a Comment