Closed bhargav-lime closed 1 year ago
@schnuerle Any suggestions around this?
I agree with @bhargav-lime here, 202 seems more appropriate (source MDN)
The HyperText Transfer Protocol (HTTP) 202 Accepted response status code indicates that the request has been accepted for processing, but the processing has not been completed; in fact, processing may not have started yet.
Further, 102 seems to be deprecated and on the way out (also via MDN):
Note: This status code is deprecated and shouldn't be sent any more. Clients may still accept it, but simply ignore them.
Ok since this is a very logical change that should be made, it's now part of the MDS 2.0 draft.
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
Let me know asap if you have any concerns.
In Provider endpoints category, the endpoints /status_changes and /trips would return status code 102 when data is still under processing. Due to nature of data analysis and compute system underneath, it may not be possible to compute the data right away. It may take some time until complete data is available to process the request. 102 status code is not the correct HTTP code under such circumstances since, in most cases, it would not be able to compute the data in reasonable time-frame and defeats the purpose to keep the connection open to optimize the resources. I feel that status code 202 would be appropriate choice here so clients can drop the connection on their side and server may queue the request and process once all the necessary data is available.
Links: /trips /status_changes