Move Asynchronous Execution to future work

[cportele]

The Asynchronous Execution requirements/conformance class should be moved outside of Core and to a future part.

Rationals: Current implementations all seem to focus on synchronous execution, which is much simpler to implement for both servers and clients. In that sense, asynchronous execution is not a core capability and that should be reflected in the scope of Part 1.

As discussed in #37, the parts of the current requirements class that deals with sharing and managing route resources (GET on /routes, /routes/{routeId} and /routes/{routeId}/definition as well as DELETE on /routes/{routeId}) should become part of a new requirements class "Sharing and managing routes" (or similar) in Part 1.

[jeffharrison]

Sounds reasonable.

Best Regards, Jeff

[cportele]

Related to this is also what the server does when it cannot compute a route.

In general, the HTTP related 4xx and 5xx status codes apply, including all the cases that are not triggered by a situation during the computation of the route. Examples: 401, 402, 405, 406, 415, 502, 503, 504, etc.

The spec distinguishes the following error situations when synchronously computing a route:

• 400: The request does not conform to the requirements (e.g., the route definition is syntactically invalid).
• 422: The request is valid, but the server is not able to process the request, in particular, if the server has insufficient route network data for the request. There are the following cases: the start or end are outside of the network extent, the start or end could not be matched to a location on the network, no route could be computed between the start and end.

Like in all cases, a server would return a 500, if an internal issue occurred (e.g., the connection to the database was lost).

The Route Exchange Model currently still discusses different states of a route resource, inherited from Processes ("accepted", "running", "successful", "failed"). If we move the async execution to a future extension, we can and should also simplify the Route Exchange Model and remove the status information (either an error is returned or a valid route) and all statements related to the states "accepted", "running", and "failed". If/when needed, they could be re-introduced as part of the async extension. "accepted" and "running" do not occur in the synchronous execution, the route is returned once it has been successfully computed. "failure" is not needed, because an error situation will be reported by a 4xx or 5xx response as outlined above. A response according to RFC 7807 (application/problem+json) is recommended, see also Common, or an HTML representation of it.

[cportele]

Meeting 2021-12-09: The change has been agreed.