Automatically Resolve Coded Domains in REST Endpoints and Operations

1419
2
09-19-2012 11:30 AM
Status: Open
DrewMillen
New Contributor III

It would be useful to have automatic resolution of coded domains from REST endpoints.

The GeoServices REST Specification exposes a number of endpoints which return attribute values. Some of the rest endpoints supply automatic coded domain resolution (for example the Identify and Find resources); however, others do not. Specifically, the following REST endpoints return coded values (instead of resolved values):


  • Feature – Map Service
  • Feature – Feature Service

  • Query (Operation)

  • Query - Feature Service (Operation)

  • Query Related Records (Operation)

  • Query Related Records - Feature Service (Operation)


There may be others as well, but these are the endpoints most exercised by typical client applications.

I would like to propose a change to the GeoServices REST Specification to allow an optional parameter on these endpoints (for example, “resolveCodedDomains=true”) which when supplied would instruct the endpoint to return resolved values as opposed to coded values. I believe that this would be a non-breaking change since the default behavior could remain the same. Obviously, if subtypes are used then the coded values should be resolved according to the subtype of the feature returned.

Additionally, there are several REST endpoints which require the use of coded values in their parameters. For example, although the “Find” resource successfully resolves coded domains when returning results, clients of the operation must supply the “searchText” parameter using the coded values (and not the resolved values). Similarly, the layerDefs parameter used by Identify and Export operations of a MapServer require the use of coded values. It would be helpful if we could provide a parameter to a resource which specifies that the supplied parameters contain resolved coded domain values (instead of the coded values).

2 Comments
JohnDye2

well said

JimmyBowden

This is still (maybe more) relevant as the Utility Network makes use of subtypes with different domains applied forcing any client to have handle resolving domains. Currently some of the Esri clients do a poor job of resolving domains (Portal map viewer, Javascript api) so this could be useful for those internal use cases.