feat(fleetbase-api): driver manifests and driver password endpoints - #53
Open
roncodes wants to merge 1 commit into
Open
feat(fleetbase-api): driver manifests and driver password endpoints#53roncodes wants to merge 1 commit into
roncodes wants to merge 1 commit into
Conversation
Documents the consumable endpoints added in fleetops#304 and fleetops#305. Drivers gains three password requests. A password change is an authorisation decision rather than an attribute update, which is why it is not part of PUT /drivers/:id — that endpoint no longer accepts a password at all. The descriptions carry the two properties a caller needs to know about and cannot discover by trying: the reset request answers identically whether or not the identity exists, so it cannot be used to enumerate an organization's drivers, and a wrong code, an expired code and an unknown identity all return the same error. A new Manifests folder covers the route a driver actually drives — a manifest is an order-agnostic sequence of stops which may span several orders, or none the driver has seen as an order. Retrieve returns the stops in sequence with their places inline, so a route of twenty stops is one request rather than twenty-one. The optimize description says plainly what it is: a nearest-neighbour walk over road distances, usually a large improvement on an arbitrary order and not guaranteed optimal, which reorders the stops of one assigned manifest rather than allocating work across a fleet the way the orchestrator does. Completed and skipped stops keep their place. Listing a driver's manifests sits with the other driver-scoped requests rather than in the new folder, next to List Driver Organizations. No response examples yet: the endpoints are still in review on the fleetops release branch, and an example recorded against an unmerged branch would be a guess rather than verified behaviour. Happy to add them once merged. npm run postman:lint — 196 requests scanned in Fleetbase API, 0 errors, 0 warnings.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Documents the consumable endpoints added in
fleetops#304 and
fleetops#305.
Drivers — password management
POST /drivers/:id/change-passwordPOST /drivers/forgot-passwordPOST /drivers/reset-passwordA password change is an authorisation decision rather than an attribute update,
which is why it is not part of
PUT /drivers/:id— that endpoint no longeraccepts a password at all, which is the security fix in fleetops#304.
The descriptions carry the two properties a caller needs to know and cannot
discover by trying:
so it cannot be used to enumerate an organization's drivers
error, so reset is not an oracle either
Manifests — a new folder
GET /drivers/:id/manifestsGET /manifests/:idPATCH /manifest-stops/:idPOST /manifests/:id/optimizeA manifest is a driver's route: an order-agnostic sequence of stops which may
span several orders, or none the driver has seen as an order. Retrieve returns
the stops in sequence with their places inline, so a route of twenty stops is
one request rather than twenty-one.
The
optimizedescription says plainly what it is — a nearest-neighbour walkover road distances, usually a large improvement on an arbitrary order and not
guaranteed optimal. It reorders the stops of one assigned manifest rather than
allocating work across a fleet, which is what the orchestrator does. Completed
and skipped stops keep their place.
Creating, cancelling and deleting a manifest are dispatch operations and are
deliberately absent — they are not part of the consumable API.
Listing a driver's manifests sits with the other driver-scoped requests rather
than in the new folder, next to List Driver Organizations.
Validation
Not included: response examples
The endpoints are still in review on the fleetops release branch. An example
recorded against an unmerged branch would be a guess rather than verified
behaviour, and this repo's own rules ask for spec updates backed by verified
API behaviour. Happy to add them in a follow-up once fleetops#304 and #305 merge
— say the word and I will capture real responses against
dev-v0.6.61.