GET to resource root, such as /rest/datasets or /rest/files, retrieves a list of objects, as per usual REST convention. By default paging is forced to avoid time-consuming accidents. To disable paging, optional query parameter no_pagination=true can be passed to instead retrieve all records in a single request.
An additional query parameter stream=true can be passed to stream the responses instead of downloading in a single file. In order to use streaming, no_pagination=true must also be passed. This option can only be used with list-apis.
# 201 created, some successful, some failed. If even one operation was a success, the general status code is 201.
# 400 bad request, all failed. Only if all operations fail, the general status code will be 400.
In list create, if even one object was successfully created, return code will be 201. Only if all create operations have failed, return code will be 400.
Resource root urls such as /rest/datasets also accept PUT and PATCH requests for bulk update. Provide the parameter objects as usual, except wrapped inside a list.
Return values are similar to bulk create, i.e. the response contains the keys success and failed, with updated objects and possible error descriptions found inside.
Only the API /rest/files currently supports bulk delete, and is reserver for Fairdata service use only.
Bulk create and update operations take an optional boolean parameter atomic, which can be set to ensure that either all operations succeed in the request, or none at all. When using the parameter, if the request fails, there is an extra field detail in the response result (in addition to the usual fields success, and failed) which reminds that the failure occurred due to the atomic flag.
Example: Trying to create 10000 files by sending request to POST /rest/files, and 10 file creations fail for whatever reason. By providing ?atomic=true, no files at all are created.