Would be nice to include both a start and end time.
With the two you can get the elapsed time which is also useful to know. So that might be used instead of one of the start/end times.
Justification for this information:
People like me want to get a sense of how long something took (elapsed time) and that is something the server side can more accurately provide.
There is a larger issue going on perhaps that I believe that since the API has to have some state, we should reduce the necessity of the client having to have persistent storage.
If you by this argument that we make more use of the api's persistent store (and some of this will be added as a separate issue), then when listing what analysis have I run, I am probably interested in either the order they were run, or the order they were finished. (Or both).
birdofpreyru
commented
6 years ago
@rocky commented on Sun Aug 12 2018
Would be nice to include both a start and end time.
With the two you can get the elapsed time which is also useful to know. So that might be used instead of one of the start/end times.
Justification for this information:
People like me want to get a sense of how long something took (elapsed time) and that is something the server side can more accurately provide.
There is a larger issue going on perhaps that I believe that since the API has to have some state, we should reduce the necessity of the client having to have persistent storage.
If you by this argument that we make more use of the api's persistent store (and some of this will be added as a separate issue), then when listing what analysis have I run, I am probably interested in either the order they were run, or the order they were finished. (Or both).
Note this is related to issue #18 .
@birdofpreyru commented on Wed Aug 15 2018
Better include these into GET /mythril/v1/analysis/:id