openmobilityfoundation
status_changes incomplete data status code representation
Is your feature request related to a problem? Please describe.
MDS 1.2 specification states the following about provider/status_changes endpoint response:
For hours that are in the past but for which data is not yet available the API shall return a 102 Processing response.
Using HTTP 102 could be problematic in some contexts as it was originally designed for WebDAV and is also not part of HTTP 1.0 specification. It is designed for long-running operations with a "progress" semantic/reporting which can not be easily applied for status changes processed later on (such as trips). Response timeouts (due to long-living connections) and reverse-proxy support can also be problematic
Describe the solution you'd like
Preferably using other status codes which are more backward compatible with HTTP 1.0 and also easier to use in any context.
Is this a breaking change
- Potentially if clients count on it
Impacted Spec
-
provider
Describe alternatives you've considered
Suggestion: use HTTP 202 Accepted. By design it's a noncommittal status code that indicates that the request is acted upon but the content might be partial. The client in this case would need to re-request the status changes later on until HTTP 200 OK is seen which indicates completeness.
See the how 102 Processing is now changed to a 202 Accepted response here:
https://github.com/openmobilityfoundation/mobility-data-specification/tree/release-2.0.0/provider#trips---responses