Add API-specification #28
Conversation
vetlek
force-pushed
the
api_contract
branch
7 times, most recently
from
8d7fc8e
to
119f08c
Compare
| InspectionType: | ||
| type: string | ||
| description: Valid inspection types | ||
| enum: ["thermal_image", "image", "audio"] |
There was a problem hiding this comment.
Should InspectionType, ReportStatus, and RobotStatus enums be reviewed and aligned with the enums in the database pr #32?
docs/openapi.yaml
Outdated
| summary: Lookup map of the area where the robot is located | ||
| description: | | ||
| ### Overview | ||
| Lookup map of the area where the robot is located |
There was a problem hiding this comment.
Should this return the map or the name of the map?
docs/openapi.yaml
Outdated
| ### Overview | ||
| Adds a new event to the robot schedule | ||
|
|
||
| New entries to the schedule can be added as long as they don't conflict with already scheduled events. |
There was a problem hiding this comment.
What would a conflict look like? Is it if they are scheduled for the same time? Should this by default add to mission queue?
There was a problem hiding this comment.
Conflict is that the new event overlaps in time with already scheduled events. I think the user then should be informed about the conflict and which event(s) it is in conflict with instead of some default action.
There was a problem hiding this comment.
Agreed, that this should be the behaviour once some time for the inspection has been requested by the user, but should the default behaviour be that it is just entered into a queue and the user would then specify a specific time window if that is desired? I would guess that for many missions one does not care that much about when it is performed, just that it happens within a reasonable time
| summary: Start a mission with robot | ||
| description: | | ||
| ### Overview | ||
| Start a mission with given id using robot with robot id. |
There was a problem hiding this comment.
Do we start it immediatly and/or at a given time?
There was a problem hiding this comment.
I think it should start immediately and create event in the case we want to start it at a given time.
There was a problem hiding this comment.
If we have some queue system for each robot instance, would this then add it to that queue so it starts at its earliest convenience or do we require that the robot is ready to start a new mission prior to using this endpoint?
docs/openapi.yaml
Outdated
| summary: Lookup all available missions on asset | ||
| description: | | ||
| ### Overview | ||
| Lookup up all available missions on asset in the Echo mission planner |
There was a problem hiding this comment.
Shall we also list the draft missions in some manner?
There was a problem hiding this comment.
Haven't thought about it. Depends on the overall workflow we want. I guess it would be natural that draft missions isn't shown outside of the echo mission planner.
There was a problem hiding this comment.
Agreed, this would probably become clear after the process with UX designer is competed
|
Are there a bit too many endpoints? I understand we might want more functionality over time, but maybe we should start on a simpler level. Maybe just a few endpoints? |
No description provided.