So we all hate at least parts of the WebADF but complaining about it won’t do anything. Dave says it is time for us to do something about it. I agree, bitching about software is therapeutic, but it doesn’t help any of us get our work done. Dave, Doron and Matt have all blogged about where we should be thinking of going on this.
Dave thinks we can create our own REST API before ESRI gets around to releasing their own API (sorry Sean, I have to use API here given the context).
There’s not really a whole lot to it if it’s designed correctly. Heck if nothing else we can use what has been done on FeatureServer.org as a road map. Suppose we cook up a server object extension (SOE) that can do all the low-level stuff in raw ArcObjects. Then we write a httphandler that can take the requests, parse the Urls and make calls back to the SOE. If we but the JSON/GEORSS/KML/whatever conversion in the SOE, we’re very light-weight on the DCOM stuff, and can get away with little to no ADF. And if we run this all directly on the ArcGIS Server box, we’re good in terms of licensing.
I like the simplicity of this. Use existing work such as FeatureServer and add back into that community and grow our own ArcGIS Server community. Matt goes one step further and outlines what this RESTful interface would look like.
So what is the next step. We can wait until the DevSummit to see what ESRI has cooked up with their RESTful attempt but I know many people are so frustrated waiting at least this long for even a peak at it we might as we create our own. It backs into where I was talking about before, long lead times with ESRI Server software puts implementors in bad spots. Still I think we should wait the month and a half to see what they’ve come up with and it makes sense to have a meetup at the DevSummit to talk about what we want to do moving forward. We can also have an IRC channel running for those who want to take part in the discussion, but can’t make it to Palm Springs. I just want to develop ArcGIS Server applications using Javascript, don’t you?
Sound like a plan?
RESTful ArcGIS is a goal we can all enjoy
UPDATE : Matt says that I should know that ESRI will fail and we should forge ahead ourselves. Frankly I’ve not seen a thing about the ESRI REST API so I guess he is probably right. They can’t even give us a taste of the thing so as far as we should be concerned it doesn’t exist. He’s got no argument from me. Lets move forward on this then. Anyone game other than Dave, Matt, Doron and me want to step up?
13 Comments
And the solution lies in…. an approach which very closely resembles what is used in open source circles. I think that episodes like these are what will ultimately drive more people to adopt OSS into their tool set. All you need now is an SVN server and a mailing list!
Take a look!
http://www.arcdeveloper.net/Default.aspx
I’m still the the process of getting the ArcDeveloper site content up to speed, but yeah – we’ve got a subversion repository, and Assembla has all kinds of project managment goodies – including TRAC, some Scrum tools, notifications etc etc.
If anyone want’s in, setup an account at Assembla.com (free) and contact me via my blog, and I’ll send an invite.
I’ve gotten a number of interested responses on my blog, so we may just make this happen. If nothing else, maybe we spur some action in Redlands.
Cheers,
Dave
James, remember the scene in “Kill Bill” where Beatrix Kiddo is trying to work chopsticks with utterly wrecked hands? Her Master, Pai Mei, absolutely insists that she eat like a human, not like a dog. He’d consider “REST API” equally low, I’m sure
You gotta love that movie.
For the record, I don’t see much here that doesn’t fit directly into the frameworks already delivered by FeatureServer and TileCache. (There are some technical limitations in FeatureServer that would need to be overcome, but that’s relatively minimal.) I’m perfectly happy to work with the community to extend either TileCache or FeatureServer in a way that anyone thinks is neccesary to make this fit their needs.
I don’t think that a new implementation of FeatureServer-like behavior makes sense. It’s possible I’m wrong. If I’m wrong, I’d like to understand why; it’s possible that FeatureServer or TileCache don’t communicate their goals well enough to understand why they already do what you want.
For example, Matt says that the replacement for TileCache (or alternative, or improvement, or whatever) should support “Google style tile requests”. Now, TileCache already supports answering TMS requests that are in the same z/x/y space as Google Maps tiles: I’ve used TileCache to serve up to VE and Google Maps with minimal effort for several different projects with no problem. (Additionally, OSM uses these type of URLs, so that’s another case to take into account here.) With that in mind, I don’t see what specifically he’s looking for here.
Matt also mentions the idea of making query results be links to specific features instead of the features themselves. This is fine if you’re working with small datasets, I suppose — and it’s definitely more RESTful — but imagine a case where I’m building a client side app, and I want to display 200 features on the map. I have to send a single query to get a list, then another 200 queries to the server to get the actual data? that seems… not ideal.
I think that there is a lot to be said for cleaning up the lacking functionality in these existing open source technologies, and even more importantly, adding documentation about how they already do what you want to do. But the fact that you don’t know how to do it already doesn’t mean that it can’t be done.
@Christopher First, let me say that you deserve some kind of award for all the truly amazing work that you have donein developing these open source tools and others. I don’t have a problem with using TileServer or FeatureServer myself. My issue is the comfort level of most Arc* developers with Python versus .Net as well as some of the difficulties some people have had in getting everything to work properly on IIS. I am not as interested in creating something like FeatureServer as I am in seeing a FeatureServer .Net port (with a few minor changes). I think this wouldl make it easier to deploy on Windows under IIS and provide an opportuiniy to plug into a lot of code that I’m sure is already out there. I did not realize that the TMS interperter was that loose and flexible as to directly hanlde tile requests form VE and others. Since the ESRI MapCache is stored in a hexidecimal encoded TMS style file structure, it seems like it would be simple to hook up with TileCache as well. So maybe just getting the community to add a few more storage and layer type providers is all that is needed for TileCache to fullfill any needs that I had in mind. For example, storing the cached tilesin raster data catalogues or adding a provider for the AGS SOAP API, etc.. As for returning links to feature resources rather than the multiple feature results: I do have this working and working well in the maps on REmapper.com. There are situations in which as many as 300 features are requested and returned, though you won’t see it in that sample map. And it is much, much faster than parsing a 300 member GeoJSON feature collection and creting VE shapes out of it. The key is that each resource is cached on client and server. I will blog more about my experience building these maps and the results I had with several different techniques soon. I appreciate your comments and direction, they are always appreciated.
I really don’t see anything here that is going to help anyone except maybe a few egos. Bottom line – ESRI is developing a REST API and simple JavaScript API’s for 9.3 AND the Web ADF is better, faster, and more powerful at 9.3. You should wait until the Dev Summit.
Last word on the street that I got was that you will be seeing/hearing about this pretty soon…
Well here you go, ask and ye shall receive.
Podcast: ArcGIS Server REST API
Jeremy Bartley and Keyur Shah discuss the ArcGIS Server REST API session at the upcoming Developer Summit that will be held March 17-20 in Palm Springs, California. Developers can learn of the content and highlights of this session.
http://blogs.esri.com/Info/blogs/devsummit/archive/2008/02/01/podcast-arcgis-server-rest-api.aspx
When considering the available options, and believe me I am, why not use the SOAP API instead of developing a license bound ArcObjects solution? It performs at least as well the ADF and the application can be placed anywhere with no license complications. The lack of documentation, examples, and support from ESRI in doing this aside, are there other reasons to bypass this option?
Also, the ArcIMS connectors were slow and quite limited compared to simply dealing with the ArcXML directly. Will the REST API have the same problems? I hate to think of waiting for it and then realizing that it is a huge performance hindrance or limited in some other hideous way.
I appreciate any thoughts on this –
Dan
@Dano: I know of alot of people who created their own solutions against the AGS SOAP api, by passing the web ADF altogether. I heard rumor of a really good flash app written against the SOAP api by one of the ESRI distributors but can seem to google it down.
If I may be so bold…
At best I’m a hack when it comes to programming but I have come to understand and accept my own personal limitations and strategize accordingly. So many challenges can be boiled down to assessing the problem, assessing resources, and taking action. I’ve seen many brilliant and intelligent posts on this forum, and I applaud the efforts of those who are inclined to put time and energy against solutions. There is something to be said for the Do It Yourself approach, but I think it could be argued that if someone could DIPLOMATICALLY organize all of the folks who share these common desires into a common voice you might get them to go in a direction that best suites you. I agree with the frustrations that have been expressed, but like it or not I know that I do not have the fiscal or mental capital to achieve anything beyond what ESRI is selling…. Why not generate the political critical mass that’s necessary to leverage ESRI’s resources? We’ve seen many Corporate responses to this blog and that is not because of James Fee (although due credit should be given for his work in creating and sustaining this community) but because the Corporations recognize the width and breadth of the community behind James Fee. So… what if we kindly remind key people who’s paying the bills and make constructive suggestions on behalf of the community that would be in everyone’s best interest? What do you all think?
@Dano: One reason to go with an ArcObjects based solution is that it allows you to access functionality that is not available through the coarse-grained SOAP API.
Neil
I really appreciate the comments.
I am sure that this is solution dependent; however, my strategy in the past was to use ArcXML for basic map querying and navigation capabilities and then have a custom ArcObjects through Web Services solution for the occasions where I really needed something more capable.
Considering the license arrangement with the ADF and ArcObjects, this seems like a very similar situation and a similar solution would suffice. As ESRI is very reluctant to provide any information or examples on using the SOAP service directly, I would love it if anyone could point me to any available resources on this.
Dan