Store a tour somebody exported, or a client recorded
const url = 'http://localhost:11044/api/v1/tours/import';const options = { method: 'POST', headers: {'X-Embabel-Api-Key': '<X-Embabel-Api-Key>', 'Content-Type': 'application/json'}, body: '{"yaml":"example"}'};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request POST \ --url http://localhost:11044/api/v1/tours/import \ --header 'Content-Type: application/json' \ --header 'X-Embabel-Api-Key: <X-Embabel-Api-Key>' \ --data '{ "yaml": "example" }'yaml carries a tour FILE, not a JSON rendering of a tour: the exchange format and the storage format are the same thing, so what is imported is what a realm would ship and what /export returned. A name a realm or this world already owns is refused with 409 rather than written, because the loader keeps what it finds and the write would never load.
Authorizations
Section titled “Authorizations”Parameters
Section titled “Parameters”Query Parameters
Section titled “Query Parameters”Username to act as, whose world holds the tours; when it resolves to a user it is used in preference to the authenticated principal. Omitted or blank, the authenticated principal acts; 401 when neither resolves
Request Bodyrequired
Section titled “Request Bodyrequired”A tour file in yaml, in the format GET /tours/{id}/export returns and a realm ships; every tour in it is stored as the acting user’s own. 409 when a realm or the world already owns a tour of that name, 400 when the file cannot be read
A tour file to store
object
The tour’s YAML, as exported or as a realm would ship it
Example generated
{ "yaml": "example"}Responses
Section titled “Responses”The tours as stored, with the ids this world gave them
Every tour declared for a world
object
The tours, shipped, realm-contributed and user-saved alike; on import, only the tours just stored
A tour: its identity, its provenance, and the client’s own declarations
object
What the tour’s own file called it — the id that survives an export
This world can remove it. NOT the same as userSaved: a tour hand-written into a user’s own config is theirs but is not this server’s to delete, so a client offering Delete for it would offer a button that silently does nothing.
Unique within this world, and what every other call addresses
Everything the tour’s YAML declared beyond id and steps, uninterpreted
object
The realm that shipped it, or absent for a world’s own and a user’s own. Carried rather than derived from the id — a namespace prefix is not something a client can reliably strip.
The tour’s steps in walking order; a step’s position here is the index the status call takes
One step, as its file declared it — minus the precondition, which stays server-side
object
Everything the step’s YAML declared except its doneWhen and when preconditions, carried through uninterpreted — the client owns that vocabulary
object
This step HAS a precondition, without saying what it is. A client that hands a step to the user can then poll for it and carry on by itself when the world says the user has done the thing — go and connect a coding agent, and the tour notices. Without this flag a client would have to poll every hand-over blindly, spending a query every few seconds on steps that can never come true.
Imported or recorded by this user, rather than shipped by a realm or the world
Example generated
{ "tours": [ { "declaredId": "example", "deletable": true, "id": "example", "presentation": { "additionalProperty": "example" }, "source": "example", "steps": [ { "presentation": { "additionalProperty": "example" }, "watchable": true } ], "userSaved": true } ]}Basic-auth challenge failed
A tour of that name is already shipped here — error names which one
Why a tour was refused, in the server’s own words
object
The refusal, as a sentence to show the user
Example generated
{ "error": "example"}
