¿Cómo puedo implementar la API REST de ESRI?

Parece que ESRI acaba de lanzar su Especificación REST de GeoServices . Creo que esto es lo que puede estar buscando.

Acabo de usar el enlace que Jason publicó arriba. No puedo imaginar cuando sea lanzado, la especificación oficial será muy diferente. Fue principalmente un rollo de mangas, arrancar Fiddler, golpear los servidores de muestra 10.0 y comenzar a piratear la implementación. No hay nada que sea imposible, solo tedioso con muchos pequeños problemas que tener en cuenta. Ni siquiera haremos nuestro 100% compatible, pero cubre el 85% y todas las apis del cliente parecen funcionar bastante bien (esa fue la única razón por la que lo hice para empezar)

Aquí hay un catálogo de demostración (hay muchos errores pequeños allí :) [bFlood - eliminado enlace viejo]

lo estamos ejecutando en AppEngine (python) y está bastante unido a las estructuras espaciales subyacentes, pero probablemente podría convertirse en un proyecto de .NET WCF decente. Aunque no estoy seguro de cómo lo distribuiríamos

saludos brian

Actualización - 3/8/12 - Acabo de ver este post emergente en stackexchange, así que pensé que actualizaría el contenido. Puede tener su FeatureService ejecutándose en minutos si prueba la versión beta de Arc2Earth Sync. el backend funciona con Google Fusion Tables y CartoDB pero estaremos apoyando a otros proveedores muy pronto. No necesitas nada, excepto ArcView 9.2 o superior ...

aquí hay una publicación de blog mostrando cómo comenzar a recopilar datos de campo en minutos usando las aplicaciones móviles de ArcGIS.com: enlace

La única documentación que conozco de la API REST de esri está en su ayuda en línea aquí:

enlace

Esto está escrito más desde la perspectiva de un consumidor que de un proveedor, pero debe ser hackeable.

Hay partes de esta API que son bastante propietarias (algunos de los formatos de salida ) e imposible de implementar por un proyecto de código abierto a menos que estas especificaciones de formato también estén disponibles.

Además, algunas de las API REST no son especialmente REST. Por ejemplo, mira el servicio de características. Parece que hay "puntos finales" separados para agregar / actualizar / eliminar / consultar en lugar de usar verbos HTTP estándar para operar con recursos. Esto me desconcierta; Sé que esri tiene algunas personas muy inteligentes que entienden REST. Supongo que estas llamadas se asignan a algún tipo de interfaz SOAP, y esri consideró que sería más fácil para ellos y para sus clientes si mantuvieran la coherencia entre ellos.

Mi opinión? Si solo desea compartir datos (no la configuración del mapa, los metadatos, etc.) y no tiene prisa, es mejor que espere hasta que Microsoft descubra cómo van a representar los tipos de datos espaciales en EDM. Con esto en su lugar, podría crear fácilmente un acceso realmente RESTANTE a sus tablas espaciales utilizando OData y probablemente OData habilitado para RIA. Esto puede ser un pastel en el cielo, por lo que sé.

¿Está pensando en exponer tablas espaciales de SQL Server 2008 Spatial? ESRI MapIt ya hace esto y creo que la licencia les permite a las personas con AGS tener acceso a ESRI MapIt.

Algunas pantallas de cómo se ve esto se pueden encontrar en mi blog: enlace

¿No necesitas escribir algo tu mismo? ;)

Saludos

Ya he hecho esto en una aplicación. No implementé completamente la API REST completa, pero sí lo suficiente para obtener una tarea de consulta para ejecutar y formatear el JSON correctamente. Utilicé ASP .NET MVC para construir mi punto final. Intenté hacer esto hace aproximadamente un año con WCF y la salida JSON no estaba formateada de tal manera que funcionara. El truco con MVC es asegurarse de tener un resultado JSONP que tire del parámetro de consulta de devolución de llamada y haga la respuesta jsonp correcta. Voy a tratar de publicar algo. Puedes ver la respuesta aquí:

enlace * & outSR = 4326 & callback = dojo.io.script.jsonp_dojoIoScript2._jsonpCallback

enlace

enlace

enlace

Parece que puede que simplemente termine reemplazando la funcionalidad de ArcGIS haciendo eso. Recomendaría utilizar un proyecto de código abierto existente para implementar dicho sistema si hay uno disponible que sea compatible con esa API, tal vez escriba su propio adaptador para un proyecto de código abierto. Tal vez exista una pero no la he visto muy dura todavía. No estoy seguro de que hayan lanzado una especificación completa de la API por el momento, pero si tiene prisa, puede utilizar la documentación de la API existente y probar su implementación con el software ESRI existente.

enlace

Uso del servicio REST con GeoServer

enlace

Aquí hay un ejemplo: enlace

@JasonBirch: creo que el principal atractivo incluso para hacer esto es la capacidad de integración con esri apps / apis / arcgis.com. Si esri tira del enchufe al usar estos a bajo costo (gratis), se vuelve mucho menos importante. No me queda claro qué planean hacer con ArcGIS.com e incluso cómo se licencia ahora. Lo vi como una ubicación central para datos / servicios donde las aplicaciones web podían registrarse, algo así como una tienda de aplicaciones para datos esri. Los terceros registran aplicaciones web (nube) para múltiples inquilinos, esri realiza un corte y su aplicación está disponible al instante para todos los usuarios compatibles con la especificación de api del resto. En este sentido, tiene sentido abrir la API de descanso y permitir que la mayoría de los servicios se integren con el hub como sea posible. la búsqueda / almacenamiento de datos geoespaciales está en camino de ser comercializada, así que muévala hacia arriba e intenta controlar el espacio de la aplicación.

Creo que su comentario de OData tiene mérito, pero en mi opinión, eso es un error. y, lo que es más importante, sin una aplicación cliente ampliamente distribuida y apreciada (algo así como Google Earth), cualquier especificación bien escrita tiene el potencial de marchitarse en la vid. No digo que ese sea el caso con OData, hay muchos desarrolladores de MS que lo pueden conectar gratis en VS, pero no lo veo en el corto plazo. mis 2 centavos ...

(por cierto, parece que hay una longitud de comentario bastante corta, por lo tanto, la nueva respuesta)