URL QueryString Point format


I have a question about the point parameter in the query string. Why do we generate multiple points like point=Lat1,Lon1&point=Lat2,Lon2?

Is there a reason why we not use for example point=Lat1,Lon1,Lat2,Lon2 or even encode the points.

Right now I mostly care about the /route request. I can see why it makes sense for the frontend url, since it may happen that the Geocoding might return a comma.

I see some issues with the current format. The query string is defined as key-value non-hierarchical data. There are lots of tools that implicitly or explicitly parse the request wrong. For example there are tools that only use the first or last occurring element with the point key. Other tools understand that this is an array, but ignore the order of the parameters, which produces wrong results.


I’m not sure I understand the question fully but at the time the decision was made it was just for simplicity AND consistency for the frontend and the backend. Furthermore for the next version I would prefer using JSON also for the request which makes URL requests more complex but opens up more compact and consistent formats e.g. also for a map matching or matrix api.

There are lots of tools that implicitly or explicitly parse the request wrong

You can define your frontend query format like you want and just forward it to the backend as appropriate. But again: not sure I understand this fully.

Well the intention of this question was to propose a change to the query parameters. Before, I wanted to understand your reasons to create the current url scheme. I thought that there might be good reasons why the scheme was created.

But if you want to change the querystring to JSON, that would be the better approach in my opinion. So we would have a JSON Object containing the points and all the other request parameters and Stringify that object and put it as querystring?

Yes, that is the point I care about. When I go to GraphHopper Maps and do a request, the URL will look something like:'https://graphhopper.com/api/1/route?point=42.940339%2C-108.632812&point=42.55308%2C-82.265625&.....
For example a HTTP Proxy or an API Gateway parses the query string and only forwards one point or changes the order of the points. That is a downside of that scheme. Therefore, I wanted to propose to create a fallback to only pass one point to the api, that contains several points. I can change that for my setup, but it would be better in my opinion to change it for GH. Also it would be easy to support both versions (I guess, haven’t tested it).