ArcGIS Server 9.3 REST API First Looks, Part 1

Esri-logoImage via Wikipedia

You may (or may not) know that I am one of the authors of the ArcDeveloper REST API, which is an open source REST API for ArcGIS Server that can be used against ArcGIS Server (AGS) 9.2, right now, free to all comers, no waiting, etc.  If you know that, you probably know that ESRI is releasing it’s own REST API for AGS at 9.3, due out later this year.  So, I thought I’d take a few posts to show you how the REST API (in beta) is looking.  For the impatient, it looks great.  For others that may not have the beta, read on.

So, first off, we are just gonna check out the very basics of the REST API.  When you install 9.3, there is no real indication of anything all that different.  The AGS Service Properties dialogs look (basically) the same, except for some (hugely exciting, but beyond the scope of this article) changes to the Caching tab.  The real excitement comes when you start messing around with URLs against your map server.  BTW, I am using Fiddler2 with the JSON Viewer plug-in to send requests to the server and look at the results.

AGS 9.0 and later have always exposed a SOAP endpoint for each service it publishes as well as service catalog.  There is a whole SOAP API, which is my preferred method to interact with AGS services, and the URL to the SOAP service catalog looks like:

http://server/arcgis/services

Following this pattern, the REST API brings along a similar service catalog endpoint:

http://server/arcgis/rest/services

The new-kid-on-the-block REST URL is even cooler, though, as it formats the results into a cool “ArcGIS Service Explorer” that looks like:

ArcGIS Services Explorer at 9.3

Which allows you to look at metadata about your services, view them in Google Earth (how cool is that?), ArcMap, ArcGIS Explorer, or the new ArcGIS Javascript API (a subject of posts to come).  Also, you can drill-down into your service and get layer info, spatial reference, unit info, and tiling information.  In fact, on the tiling information, you can actually LOOK at some of the tiles.  Other information includes supported operations that you can execute within the Explorer, like Export Map or Identify.  Here’s a picture of the service page:

Tons of info right out of the box.

Another item the Service page has is a “Supported Interfaces” section, which I would call supported formats.   The ones listed out of the box are REST and SOAP.  Clicking on the REST link will give you all (well, most of) the information just mentioned, but in JSON format .   Here, lemme show you:

Fiddler (w/JSON Viewer) display of REST GET Request of AGS

The only difference between the URL to get to the cool HTML Services Explorer page and the URL that spits out JSON is the addition of a ‘f’ (for ‘format’) querystring parameter, like so:

http://server/arcgis/rest/services/ServiceName/MapServer?f=json

MMMMM….now, THAT’s some good REST.

There is similar love for supported operations, allowing you to crank out a quick image or perform a Find and look at the results.   Also, the (impressively comprehensive) API reference is linked on the Services Explorer pages, which, oh by-the-way, takes you here.

Finally, the last thing I want to cover in this post is the REST admin inteface.  If you go to the following URL in your browser:

http://server/arcgis/rest/admin

you’ll be hit with a login screen for the ArcGIS REST API Admin application.  It’s pretty sparse right now, not even meriting a screen shot.  Currently, you can use the admin site to tell AGS when to recycle the cached service responses and to turn on the REST Services Catalog.  Now, that second option was nowhere to be found in my admin app, but the docs assure me it’s there.

So far, the only disappointment I have had is that ESRI has chosen not to use GeoJSON as their format to return features in (or, for that matter, even as an option).  I don’t profess to know why, but I’ll try to float that to one of my contacts on the mother ship soon.

Summing up, the AGS REST API looks great before you even show a map on a site.  I am hoping to go that in future posts.

Advertisements

About Ruprict

I am a nerd that is a Nerd Wannabe. I have more kids than should be allowed by law, a lovely wife, and a different sense of humor than most. I work in the field of GIS, where I am still trying to find myself on the map. View all posts by Ruprict

5 responses to “ArcGIS Server 9.3 REST API First Looks, Part 1

  • Dave

    Asked Jeremy @ GeoJSON, and it’s not in 9.3 final, likely in a SP.

  • Marcel

    Fascinated by the new REST API, I started exporing the Web, looking for information about RESTful(ness). On Wikipedia I found that one of the principles of REST is to rely on “a constrained set of well-defined operations”. If I’m not mistaken these operations are defined by the HTTP protocol an include GET, POST, PUT, HEAD, DELETE, TRACE, OPTIONS an CONNECT. Isn’t it contradictory if the AGS REST API defines its own additional operations like identify, find, GenerateKML, …?

  • ruprict

    @Marcel–good question. Really good question.

    REST is based on the ideas of Resources (defined by URIs/URLs) and verbs (the HTTP verbs you list) As far as the identify, find, etc operations you mention, I think the proper way to REST-a-fize them would be to make them params to a GET request. The AGS REST api puts identify in the URI which, arguably, is against the REST architectural style. “identify” is an operation, not a resource.

    Example AGS REST Identify URI
    http://sampleserver1.arcgisonline.com/ArcGIS/rest/services/Specialty/ESRI_StatesCitiesRivers_USA/MapServer/identify?f=json&geometry%5B…%5D

    Following “strict” REST, it maybe should be
    http://sampleserver1.arcgisonline.com/ArcGIS/rest/services/Specialty/ESRI_StatesCitiesRivers_USA/MapServer?op=identify&f=json&geometry%5B…%5D

    So, you pass the operation to perform (identify) as a parameter to the GET request of the mapservice resource. In other words, I think you have a point.

    Having said that, one of the reasons (IMO) that REST is so popular is its inherent flexibility. It makes it easy to use services to get things done, which (again, arguably) SOAP does not. I think both styles have their uses, but REST is much, much easier. In fact, I have a hard time using the words “strict” and “constrained’ in the same sentence as REST

    I am, however, fully prepared to be wrong about this….

    Thanks for the great comment.

  • Braden

    Does the REST api provide functionality to view metadata for the spatial layers in a map service, or the ability to view those layers’ attribute tables? Are these abilities inherent in ArcServer itself, even?

    thanks,
    Braden

    btw, this all new to me, as I’m sure is evident by my questions, so thanks!

    • ruprict

      It really depends on what you mean by metadata. If you mean the FGDC stuff, then no. That is still only handle by the (soon-to-be-dead?) ArcIMS Metadata service, as far as web publishing. However, the REST API does expose a good bit of metadata, which you can see an example of using ESRI’s sample servers:

      Map Service

      Layer Info

      As far as “Open Attribute Table”, that doesn’t exist as such, but you can query layers and get back features, etc.

      Hope that helps,
      Glenn

      Oh, and this is new to most people, so no worries!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: