API compatibility issues with python bindings

Dear ORS community,

I’ve been trying to use the python bindings (from the openrouteservice-py project) with a downloaded and locally run version of openrouteservice (using the docker build task).
I sadly could not get it to work so far, because there seems to be an incompatibility between the latest version of the python bindings (I am using v1.1.6) and ORS v4.7.0.
Most obvious is a mismatch in API endpoint names (e.g. for route calculation):

  • python bindings call /directions
  • official API documentation says its /directions
  • but code (v4.7.0) clearly says its /routes

I suspect that I haven’t found the correct branch / tag yet to use with the latest version of the python bindings.

Could you point me into the right direction here? (pun intended)

Hi @flonix8 - this is correct.

The reason for this is that our SDKs point to a gateway layer exposing different API slugs. Could you please open an issue in the ors-py repo that we can introduce a new option in the client to consider this? Thanks a bunch, Tim

Hi @flonix8,

calling a local instance is described in the README:

We will consider renaming /routes to /directions in ORS v5, to be released in a few weeks. Then you can use localhost as you would the ORS live instance.

Thank you for the hint @nils ! It was late last night, didn’t manage to read between the lines.
Is the endpoint name the only thing that is different or is there something elso to keep in mind?

@timothy: Thank you. Will do!
Is the gateway layer also on github?

@flonix8 it isn’t, no. It is used for the user management / authorization when accessing the public API. With this in place, there is no need to add an issue, I also wasn’t aware that this feature already exists in the python package :wink: cheers and happy new year!

No worries. I can see that it’s weird (and historical) that it’s called /routes in our repo.

There shouldn’t be anything else you need to be aware of. If you’d want to get your own gateway middleware with authentication, you’d have to alter the _DEFAULT_BASE_URL parameter to reflect your own:

Next version will have /directions btw:

Awesome! Thanks for the help, guys.