Full vs Partial Responses
The Build, Sequence, Insert, or Evaluate normally return a problem_response, which only contains a subset of the full problem data.
When the return_request field is set to true
, the full problem is returned instead.
Integrations are sometimes simpler when the entire input is pipelined through to the output.
Note
This method is asynchronous and requires authentication. See Asynchronous Tasks and Authentication for more information.
Overview
Instruct RouteCloud to return the input back in full by setting the return_request flag to true
in the respective request.
The resulting response will be identical to the original request, except for the following differences:
- Any jobs defined inline in route.jobs or route.stops will be placed into the top-level jobs array; the stop.job field will contain only the id of the job.
- The route_response objects that would usually be returned as a top level array will be placed in the route.response field of their respective routes, except for the route_response.stops field.
- The route_response.stops field from each route response will be placed in the route.stops field of their respective routes.
Example
Build Request
{
"id": "returning_full_request",
"routes": [
{
"id": "route0",
"location": "39.718005, -104.969531",
"date": "2017-04-11"
}
],
"jobs": [
{ "id": "job0", "location": "39.635928, -105.049219" },
{ "id": "job1", "location": "39.725375, -104.791080" },
{ "id": "job2", "location": "39.708990, -105.026954" }
],
"return_request": true
}
The returning_full_request.json request. Click here to open it in the UI.
Build Response
{
"jobs": [
{ "id": "job0", "location": "39.635928,-105.049219" },
{ "id": "job1", "location": "39.725375,-104.791080" },
{ "id": "job2", "location": "39.708990,-105.026954" }
],
"routes": [
{
"id": "route0",
"date": "2017-04-11T00:00:00",
"location": "39.718005,-104.969531",
"response": {
"cost": 36.17,
"internal_cost": 155.05,
"distance_meters": 70108.0,
"working_time": "01:28:36",
"driving_time": "01:28:36"
},
"stops": [
{ "type": "depot", "arrival_datetime": "2017-04-11T00:00:00", ... },
{ "type": "job", "job": "job1", "arrival_datetime": "2017-04-11T00:26:54", ... },
{ "type": "job", "job": "job0", "arrival_datetime": "2017-04-11T00:59:58", ... },
{ "type": "job", "job": "job2", "arrival_datetime": "2017-04-11T01:16:00", ... },
{ "type": "depot", "arrival_datetime": "2017-04-11T01:28:36", ... }
]
}
],
"return_request": true,
"id": "returning_full_request"
}
A snipped version of the returning_full_request.json response. The full response is available here. Click here to open in the UI.
The response object consists of all the information provided in the request, along with a route_response object and an array of stop_response objects that contain all of the route information that a build request would usually return.
The return_request flag is still true
, meaning that this response can be passed directly into another call and the full request is returned again.
See Also
- The return_request field for Building Routes.
- The return_request field for Sequencing Routes.
- The return_request field for Inserting Jobs.
- The return_request field for Evaluating Routes.