Table of Contents
It includes info to help developers using the Postman collections:
- Steps to get started
- Link to documentation guides
- API error codes
- Reference documentation
- Community & feedback
View: ArcGIS Location Services 🗺️ - Postman workspace
View: Environments > Standard endpoints
There are two sets of local environment variables (green box) which includes:
- Set of endpoints for ready-to-use services.
- Temporal variables used in workflows (like job_id for async operations).
- For Enterprise users we recommend to create a custom environment.
The Global set ("Globals"; yellow box) is used to set credential to generate short-lived access tokens: user and pass, client_id and secret.
Local and Global variables are used in the requests definitions using {{variable name}}:
View: 2. 📍 Geocoding & Search API (Geolocation) > Search / Geocoding (Addresses & Places) > 💡 Examples > Search address
There is a Collection (root folder) per each service:
-
- ☁️ Data hosting
- ... (it will evolve in the future)
View: 1. 🔒 Get access token
Each collection include documentation related with the service (service specs, APIs availables, etc). But also some include "Pre-request Script" and "Test" common to all operations (like 📍 Geocoding & Search API (Geolocation))
And it also contains:
-
A folder for each operation supported by the service (e.g. in Geocoding & Search: direct geocoding, reserve geocoding, batch geocoding, etc.).
-
A folder with requests to query service metadata, field structures, etc.
View: 2. 📍 Geocoding & Search API (Geolocation)
We are going to illustrate the structure using the "Find routes and directions" operation within the "🚙 Routing & Directions API" as an example:
This and other operations includes:
-
"Pre-request Script" and "Test" for this operation and common to all examples.
-
One or two "spec requests template" with all the parameters described in the specification (
*-spec). There will be one or two depending on whether the operation supports a direct/sync (➡️) and a job/async (🔄) request or not. -
A "Examples" folder with sample requests that matches the examples in the Mapping APIs and locations services guides.
Each request in turn ( operationName-spec) includes:
- A short description, an image, and a link to the REST API doc and related guides in the developer guides.
- All accepted parameters (disabled by default), each with:
- A short description (coming from the API reference).
- The value types that the operation support, using the value
<FieldName>to referrers that it is a special JSON object with a given structure (more info in the REST API doc).
In addition to the query parameters, some requests also uses path variables. These can be identified because they uses a "colon" as a prefix (:variableName) as you can see in the following images:
The structure of the directory depends on whether or not it supports async/jon requests or not:
- If it only support sync/direct requests (➡️): the folder will include some examples requests directly within the folder.
- If it supports sync/direct (➡️) but also async/job requests (🔄): the folder will contain folders for each type of request. The async/job will contain several numered requests (with a ✅) illustrating the usual workflow.
As you can notice, each example request includes a sample response:
Another thing to note, is that to facilitate the execution of the asynchronous example requests, a code has been included in the "Test" tab which, after receiving the response that initiates the task (submitJob), it sets the job_id in the environment variables to allow the concatenation of the following requests:
When using the Postman native app, some requests will include a visualization of the results, like shown in this direct geocoding request:
And as mentioned before, in this folder we can find some useful requests that might be referenced from the other requests:
