taurus-datajob-api 3.1.3
Taurus Data Jobs
Keywords: OpenAPI,OpenAPI-Generator,Taurus Data Jobs

The Taurus Data Jobs internal and Control Plane API. Data Jobs allows Data Engineers to implement automated pull ingestion (E in ELT) and batch data transformation into Data Warehouse (T in ELT). See also https://confluence.eng.vmware.com/display/SUPCR/Data+Pipelines+User+Guide  The API has resource-oriented URLs, JSON-encoded responses, and uses standard HTTP response codes, authentication, and verbs. The API enables creating, deploying, managing and executing Data Jobs in runtime environment.&lt;br&gt; ![](https://confluence.eng.vmware.com/rest/gliffy/1.0/embeddedDiagrams/c0a4fed2-0229-4baa-b192-c8ae6ad6ad28.png) &lt;br&gt; The API reflects the usual Data Job Development lifecycle:&lt;br&gt; &lt;li&gt; Create a new data job (webhook to further configure job -e.g authorize its createion, setup permissions, etc). &lt;li&gt; Download keytab. Develop and run the data job locally. &lt;li&gt; Deploy data job in cloud runtime enviornment to run on scheduled basis. &lt;br&gt;&lt;br&gt; If Authentication is required pass OAuth2 access token in http header &#39;Authorization: Bearer [access-token-here]&#39;  The API promotes some best practices (inspired by https://12factor.net ): &lt;li&gt; Explicitly declare and isolate dependencies &lt;li&gt; Strict separation of config from code. Config varies substantially across deploys, code does not. &lt;li&gt; Separation between the build, release/deploy, and run stages &lt;li&gt; Data Jobs are stateless and share-nothing processes. Any data that needs to persist must be stored in a stateful backing service (e.g IProperties). &lt;li&gt; Implementation is assumed to be be atomic and idempotent - should be OK for a job to fail somewhere in the middle; subsequent restart should not cause data corruption. &lt;li&gt; Keep development, staging, and production as similar as possible &lt;br&gt;&lt;br&gt; &lt;b&gt;API Evolution&lt;/b&gt;&lt;br&gt; In the following sections, there are some terms that have a special meaning in the context of the APIs. Their definitions are re-used from https://confluence.eng.vmware.com/display/SUPCR/API+Evolution+Cycle &lt;br&gt;&lt;br&gt; &lt;li&gt; &lt;i&gt;Stable&lt;/i&gt; - The implementation of API has been battle-tested (has been in production for some time - probably at least a month)                      API is subject to the semantic versioning model and will follow                      deprecation policy - https://confluence.eng.vmware.com/display/Standards/API+Deprecation+Policy &lt;li&gt; &lt;i&gt;Experimental&lt;/i&gt; - May disappear without notice and is not subject to semantic versioning                            Implementation of the API is not considered stable nor well tested.                            Generally this is given to clients to experiment within testing environment. Must not be used in Production. &lt;li&gt; &lt;i&gt;Deprecated&lt;/i&gt; - API is expected to be removed within next one or two major version upgrade.                          The deprecation notice/comment will say when the API will be removed and what alternatives should be used instead.   # noqa: E501