Large scale geoprocessing through ESRI REST interface?

Question

A typical limitation of web based processing is that urls are limited to 2 thousand characters for a GET request. From my understanding of how the ESRI Javascript API works, JSONP is utilized to interact with ArcGIS Server Geoprocessing services via the REST API, requiring the use of a GET request?

This seems to pose a problem if I'm attempting to send large quantities of user defined runtime data (> 100 coordinate pairs and several other user parameter strings) to be worked upon in a geoprocessing service via the standard ESRI Javascript API.

What's the best way to tackle this problem?

I'm thinking about writing a proxy service that will receive GET requests, but will issue POST requests to the REST API.

Answer 1

I'm not sure, there might be a way to POST to a GP service, but I chose this approach instead:

Write a standard WCF REST site using the online project template. Modify the site to allow you to POST large objects (as json) where other sites can see them as a resource (with a URL). (I just saved json streams to files.)

When calling the GP service, pass the URL as an argument. The gp service GETs the object from the WCF site referenced by the URL, and DELETEs it upon successful completion.

While it does make things a bit more complicated for the client, it simplifies debugging. By refactoring my GP tool, I can pass a url to it and step through it with the debugger. Also having a history of job inputs that I can review is helpful.

Update:

Also, I forgot to mention, if your WCF Rest service is on the same machine as your GP service, you can have the WCF svc return the filepath of the resource, then the client can pass that to the GP service. That way the gp service doesn't need to retrieve the job input from the WCF service - it can just open the file directly.

Answer 2

Yes, the JavaScript API by default use GET, which most browsers limit to about 2K.

I think the best way to tackle this problem is what you suggested yourself (for larger requests, use a proxy page). This is documented in the Resource Center for the ArcGIS API for JavaScript, which also include example proxy pages in multiple languages. http://help.arcgis.com/en/webapi/javascript/arcgis/help/jshelp_start.htm#jshelp/ags_proxy.htm (Using the proxy page)

Answer 3

My current flag-ship app has us actually going a slight different way. I have my users to submit to me a file (csv is the easiest) that I import into a SQL staging table; then I pass that table name to my Rest Services as a variable where I do the processing.

I have users sending me files that are over 35K points with additional attributes that are used further down the process.

Your thought process you have there may be the best for your solution, having your own service that can accept the larger dataset, then que up batches to go to the REST service and responds back to yours where you aggrigate those responses and then send the total response back to the user.