On Being More RESTful

[Anonymous User]

In general, the ArcGIS Server REST implementation is a great RESTful API. There are, however, some things that could be improved. I would like to use this thread to identify ways that the REST API could be made more RESTful. Below are two items to start the discussion.

* Make use of HTTP status codes.

Example: http://sampleserver3.arcgisonline.com/ArcGIS/rest/services/Hydrography/Watershed173811/FeatureServer...

When a resource is requested that does not exist, an HTTP response is sent with the status "200 OK." The body of the response contains more information which is great but users of the API should be able to tell a "Resource Not Found" situation by simply looking at the HTTP status code.

Status codes as a whole should be reviewed and made to align more with other REST service implementations. Correct me if I'm wrong but the GeoServices specification does not stipulate what status codes to use. This would be a welcome addition to the specification as well as the GIS Server implementation.

* Make use of HTTP message bodies for POST requests.

Example: N/A

POST requests should use HTTP message bodies to express resources instead of query strings. This isn't just an issue about being RESTful; when a POST request contains complicated geometries, the URI's become exceedingly long and can be rejected by web servers for that reason. HTTP message bodies would get around this issue. In addition to this, it is standard REST practice to use message bodies for POST and PUT requests.

I understand that this would be a change to the GeoServices specification as well as the GIS Server implementation but it could be done in such a way that either form of request is supported (query strings vs. message bodies).


Does anyone have anything else to add?

[RichardWatson]

Another thing that could be done is support for HTTP verbs other than GET and POST.

The one thing that I have figured out is that ESRI made a set of choices based on state of the industry at the time.  Unfortunately, I never found an article which summarizes this and have only pieced it together over time.

For example, I believe that the reason why HTTP status codes are not supported is because of callbacks.  If you have a callback function then it will not be called when an error occurs.

At the 2011 Developer Summit, I heard (for the first time) a speaker discuss why only GET and POST are supported.

[Anonymous User]

That's informative, Richard, thanks!