Select to view content in your preferred language

How to interpret non-standard response for add-to-definition-feature-service rest endpoint

130
1
12-09-2024 12:53 PM
chris_del101
Occasional Contributor

I'm using the REST endpoint https://developers.arcgis.com/rest/services-reference/enterprise/add-to-definition-feature-service/#... to "fill in" a feature service based on this post https://community.esri.com/t5/arcgis-geoevent-server-questions/create-a-feature-class-in-spatiotempo... 

The docs give the response type as having a "success" or "error". example

 

 

 

{
 "error": {
  "code": 498,
  "message": "Invalid Token",
  "details": []
 }
}
{
 "success": true,
 "layers": [
  {
   "name": "Layer_fd051a93_3efd_44ea_ba79_28eeee296e47",
   "id": 2
  }
 ]
}

 

 

 

 

When the request works properly I get a response like one of these, but around 50% of the time I get back a response that I don't understand. It's just a bunch of values. 

There is almost no processing time, whereas a working request with response above takes a few seconds. There are also no error logs telling me what is happening. The actual functionality of the endpoint fails too.

The post data that I send with this request is data that I have verified and has worked in previous requests. The success response above came from one of those. The successes have all be using Postman via the Oauth2 scheme. 

The prod use case will use the token in the URL, and this type of call produces this invalid response type 100% of the time. 

 

This is it. What does this mean???

 

 

 

{
 "initalExtent": "None",
 "adminServiceInfo": {
  "database": {
   "datasource": {"name": "/nosqlDatabases/AGSDataStore_bigdata_bds_j7wheboq"}
  },
  "name": "Service_1335b0ec_e2a6_4f71_920c_d34a5f5288e8",
  "type": "FeatureServer",
  "status": "STARTED"
 },
 "allowGeometryUpdates": false,
 "supportsApplyEditsWithGlobalIds": true,
 "maxRecordCount": 2000,
 "supportedFieldTypes": [
  "esriFieldTypeBlob",
  "esriFieldTypeDate",
  "esriFieldTypeDouble",
  "esriFieldTypeGlobalID",
  "esriFieldTypeGUID",
  "esriFieldTypeInteger",
  "esriFieldTypeBigInteger",
  "esriFieldTypeOID",
  "esriFieldTypeSingle",
  "esriFieldTypeSmallInteger",
  "esriFieldTypeString"
 ],
 "description": "",
 "units": "esriMeters",
 "maxViewsCount": 20,
 "hasStaticData": true,
 "syncEnabled": false,
 "tables": [],
 "hasVersionedData": false,
 "layerOverridesEnabled": true,
 "layers": [],
 "GUIDFormat": "O",
 "spatialReference": "None",
 "enableZDefaults": false,
 "serviceItemId": "f1528092e7c94f52a098dcd5cdc06d11",
 "capabilities": "Query",
 "xssPreventionInfo": {
  "xssInputRule": "rejectInvalid",
  "xssPreventionRule": "InputOnly",
  "xssPreventionEnabled": true
 },
 "supportsAppend": true,
 "supportsDisconnectedEditing": false,
 "maxFieldNameLength": 128,
 "supportedAppendFormats": "shapefile,featureCollection,featureService",
 "serviceAdminOperationsOptions": {
  "deleteFromDefinition": [
   "layers",
   "tables"
  ],
  "addToDefiniton": [
   "layers",
   "tables"
  ],
  "updateDefinition": [
   "allowGeometryUpdates",
   "canUseTopologicalSortForRelationshipOrdering",
   "capabilities",
   "copyrightText",
   "datumTransformations",
   "description",
   "editorTrackingInfo",
   "enableZDefaults",
   "hasStaticData",
   "hasZ",
   "initialExtent",
   "maxRecordCount",
   "preferredTimeReference",
   "preserveLayerIds",
   "serviceDescription",
   "syncEnabled",
   "syncRowsMovedOutsideFilter",
   "units",
   "xssPreventionInfo",
   "zDefault",
   "maxViewsCount",
   "supportsBiDirectionalSyncForServer",
   "layerOverridesEnabled",
   "maxIdsCount"
  ]
 },
 "currentVersion": 11.3,
 "supportedQueryFormats": "JSON",
 "name": "Service_1335b0ec_e2a6_4f71_920c_d34a5f5288e8",
 "serviceDescription": "",
 "editorTrackingInfo": {
  "allowOthersToUpdate": false,
  "enableEditorTracking": false,
  "allowOthersToDelete": false,
  "enableOwnershipAccessControl": false
 },
 "copyrightText": "",
 "supportsLayerOverrides": true
}

 

 

 

 

0 Kudos
1 Reply
chris_del101
Occasional Contributor

It looks like the cause here was a typo in the URL. Instead of a 404 the response is like this, which is very confusing. I would expect an invalid URL to just straight up fail....

0 Kudos