Latest Contributions by RayVernagus

When I point the ArcGIS Online Map Viewer at a MapService on our internal network, I get the following message: Layer 'MyService - MyLayer' seems to be on an internal network and is not accessible to ArcGIS.com. Thus, editing will be disabled on this layer. Is there a technical reason why editing is disabled? Is there any way to enable editing of internal layers? ... View more

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/1/0 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? ... View more