REST Endpoints: Difference between revisions
| Line 29: | Line 29: | ||
</pre> | </pre> | ||
== Date Inputs | == Date Inputs == | ||
While dates are always output in the same format, dates in query strings or in JSON payloads can use either the standard output format shown above, or the UTC time represented as '''milliseconds since the epoch'''. | While dates are always output in the same format, dates in query strings or in JSON payloads can use either the standard output format shown above, or the UTC time represented as '''milliseconds since the epoch'''. | ||
For example, the last second of 2012 EST is: | For example, the last second of 2012 EST is: | ||
Revision as of 04:40, 6 January 2013
For information on how common behaviour of endpoints, see Common Behaviour below.
The supported endpoints are listed below. Endpoints may be accessed either through HTTP or HTTPS as determined by your preference.
Common Behaviour
- For GET and DELETE, parameterization is done via request parameters, and not JSON body. Supported parameters are simple and primarily provide search options and simple flags.
- All non-200 responses will always return a JSON response in the following format. One or more errors may be returned in the errors property.
{
"errors":["Resource not found"]
}
- If a request does not pass validation or if an action cannot be performed, a 400 status code will be returned. This may happen if required fields are omitted, in an invalid format, or an action cannot be performed in the current context.
- If a resource with the specified identifier could not be found, a 404 status code will be returned. For example, this would occur if you attempt to load a job with an ID that does not exist.
- If an incorrect method is used on an endpoint (e.g. DELETE on a job runtime), a 405 status code will be returned.
- If no valid basic authentication is provided (see REST API), a 401 status code will be returned.
- If no endpoint exists at the requested path, a 404 status code will be returned.
- If the Content-Type header of a PUT or POST request is not application/json, a 415 status code will be returned.
- If the server encounters an unexpected error, a 500 status code will be returned.
Date Formats
Since scheduling is inherently linked to time zones and is not fully represented by a UTC time, all times in the API are returned in the following string format. Note the trailing timezone indicator which indicates the UTC offset.
yyyy-MM-dd'T'HH:mm:ssZ
For example, the last second of 2012 PST is:
2012-12-31T23:59:59-0800
Date Inputs
While dates are always output in the same format, dates in query strings or in JSON payloads can use either the standard output format shown above, or the UTC time represented as milliseconds since the epoch. For example, the last second of 2012 EST is:
2012-12-31T23:59:59-0800
Or, as milliseconds since the epoch:
1356987599000
Jobs Endpoints
GET a list of jobs
Coming soon...
POST a new job
Coming soon...
GET details of an existing job
Coming soon...
PUT updates to an existing job
Coming soon...
DELETE an existing job
Coming soon...
GET a list of an existing job's schedules
Coming soon...
POST a new schedule to an existing job
Coming soon...
Runtimes Endpoints (i.e. Job History)
GET a list of a job's scheduled runtimes
Coming soon...
POST a new scheduled runtime for an existing job (i.e. submit a one-time or ad hoc run)
Coming soon...
GET a list of scheduled runtimes (supports multiple jobs)
Coming soon...
GET details of an existing scheduled (or completed) job runtime
Coming soon...
POST a resubmission request for a failed job runtime
Coming soon...
Runtime Preview Endpoints
GET a list of runtime previews for an existing job
Coming soon...
GET a list of runtime previews (supports multiple jobs)
Coming soon...
Scheduling Hosts Endpoints
GET a list of known scheduling hosts
Coming soon...
GET details on an existing scheduling host
Coming soon...
PUT updates to an existing scheduling host
Coming soon...
