Is there value in being able to upload routes?

[jerstlouis]

Use case: calculating a route offline in client (or from some other server) and wishing to share it with others.

Is there value in a PUT operation at /routes/{routeId} for this functionality? A POST to /routes whose payload is the route exchange model instead of a routing calculation request could make sense as well if we can distinguish it by Content-Type. @cportele @skynacho @jeffharrison

[cportele]

Such a capability could also be misleading, because users will assume that routes on the server have been generated by the API, which is not the case here.

If such a capability would be added, it should be a separate conformance class and not in Core, so we can discuss this later.

[skyNacho]

I agree with Clemens this is not a core functionality, so it should not block the current process for standard candidate publication and approval.

On the other hand I think it is an interesting conversation, as so far we have not dedicated much discussion to the capabilities of API Routes to manage pre-generated routes. So far, the agreement is that POST will generate a new route, GET will allow to list and fetch pre-generated routes and DELETE will erase a route. We did not discuss the case when a route is generated elsewhere and uploaded to the API to be available for other clients. And this case can appear naturally if a client can work offline or in intermittent scenarios, with an embedded routing engine.

The PUT method is typically used to update existing resources whereas the POST method adds new resources. But it is my understanding that the PUT method can also add new resources as long as the Request URI is a valid resource URI. I have two questions at this point:

1. Should Routes API allow for clients to determine the resource identifier?
2. Should Routes API allow for being used as a routes storage, publishing routes generated by third parties, instead of being solely an interface for a routing engine?

If the answer to both questions is yes, then we should consider seriously adding the PUT method in some extension.

[jerstlouis]

@cportele @skyNacho

This came up as a question in the development of remote routes management capabilities in our client which does also have the capability to generate routes offline.

I brought this up because an important goal of the Route Exchange Model is to be able to share routes, which may sometimes be computed offline. It is somewhat related to my earlier suggestion to optionally be able to provide separate resources for the route calculation and route listing end-points.

Another related question is would it make sense to be able to to conform to the Routes API routes management conformance class without implementing support for calculating routes?

[cportele]

@jerstlouis

Another related question is would it make sense to be able to to conform to the Routes API routes management conformance class without implementing support for calculating routes?

You are correct, in general these are orthogonal capabilities on the same Route Collection resource. One is to create new routes from a route definition and the other one is manage/list/query routes just like any other resource (styles, features) using HTTP.

I see the following deployment patterns:

• Routing Core: Compute transient routes.
• Route Management: A repository for routes.
• Routing Core + Route Management: Compute routes and store them.

To support all patterns, the Route Management requirements class:

• would not depend on Core (but instead on the general Create/Replace/Delete requirements class currently in Features Part 4, just like OGC API Styles);
• would permit that APIs that also implement Core do not support POST or PUT with REM content (i.e., routes can only be created by a routing request, not submitted by a client).

[jerstlouis]

@cportele Right, thank you. That's partly where I was coming from when suggesting separate relation types for routes computation vs. for listing/retrieving/uploading/updating/deleting routes.

But it could also be that the differentiation of what the POST method does is based on the Content-Type of the payload (routing request vs. REM), or only supporting uploading REMs via PUT if that makes more sense.

[cportele]

Meeting 2022-09-20: We had different opinions whether a capability to share routes not created by the API should be part of Core or not. Is Core mainly about creating routes and being able to manage/share them or is creating routes and sharing routes separate capabilities? Since we could not agree, we will continue the discussion in the next meeting. If there are opinions, please add them to this issue.

[jeffharrison]

On Oct 18 the SWG continued discussion on this Issue. Opinions vary about whether this should be in Core. A simple solution would be to defer this to an Extension. SWG agreed to continue discussion on this Issue in the next mtg.. scheduled for Nov 8.