The REST API does not support curves to be returned.
When curves are encountered, they are densified automatically and returned as polylines.
Support for curves is being planned for in the future versions.
The shapes returned by the REST API are not GeoJSON compliant. But the ESRI developers seem open to support GeoJSON when it is finally ratified by the standards committee.
The REST API does all its work by using the ArcGIS Server SOAP API. See the notes below for the reasons why.
The ESRI developers chose to use the DOJO toolkit primarily because its graphics capabilities.
The DOJO client-side libraries provide support for performing some simple spatial operations like ‘intersection’ on the client-side.
The client-side layers provides support for attributes on the client-side features. Attributes on client-side features are not even supported in VE and Google Maps.
The client-side layers support events.
Currently, only one client-side layer is supported. The reason for this being (according to the ESRI developers) there are problems with listening to events on features that are not on the top-most layer. ESRI is currently researching the problem and is trying to find ways to make multiple client-side layers work.
ArcGIS Server 9.3 supports the following tiling scheme
Google Maps (256X256)
ArcGIS Online (512X512)
The Map cache generated using the VirtualEarth tiling scheme does not generate tiles using the quadkey naming scheme for the file names generated but only the tiling scheme is the scheme.
The REST API has built-in support for handling quadkey naming scheme, it maps the quadkeys to the file names generated by the ArcGIS Server cache.
The WMS Service of the MapServer object will start taking advantage of the Map cache if available starting in 9.3.
Sounds like SDE will support storing shapes in SQL Server 2008 as SQL CLR types also. This should enable other applications to access and use spatial data in the SDE without ArcObjects.
Note: It was decided to use SOAP over DCOM for the REST handlers to talk to ArcGIS Server because ESRI realized after running some metrics that SOAP was more performant than DCOM to access ArcGIS Server functionalities. The chatty nature of DCOM reduces its performance over SOAP. When using DCOM, the client uses a proxy to communicate with the server object.
That means every time the client accesses a property on the server object, it is accessed over the network. But when using SOAP, an object representation is completely serialized and sent to the client so that property access doesn’t need to be over the network.
Even though it is not completely documented, it is possible to access Server Object Extensions over SOAP directly with some custom programming.