Adds an API for managing saved objects

[tylersmalley]

API Overview

For brevity, I have simplified the cURL commands to exclude the necessary headers. You will need to include the following: -H "Content-Type: application/json" -H "kbn-xsrf: true". I would also suggest adding -i to confirm the response headers.

Create

Route: POST /api/saved_objects/{type}

cURL: curl -X POST -d '{ "attributes": { "title": "Test pattern" } }' http://localhost:5601/api/saved_objects/index-pattern

Response:

{
  "type":"index-pattern",
  "id":"AVwXs-2htCUMy4H_zXXl",
  "version":1,
  "attributes":{
    "title":"Test pattern"
  }
}

Read

Route: GET /api/saved_objects/{type}/{id}

cURL: curl "http://localhost:5601/api/saved_objects/index-pattern/AVwXs-2htCUMy4H_zXXl"

Response:

{
  "id":"AVwXs-2htCUMy4H_zXXl",
  "type":"index-pattern",
  "version":1,
  "attributes":{
    "title":"Test pattern"
  }
}

Update

Route: PUT /api/saved_objects/{type}/{id}

cURL: curl -X PUT -d '{ "version": 1, "attributes": { "title": "Updated title" } }' http://localhost:5601/api/saved_objects/index-pattern/AVwXs-2htCUMy4H_zXXl

Response:

{
  "id":"AVwXs-2htCUMy4H_zXXl",
  "type":"index-pattern",
  "version":2,
  "attributes":{
    "title":"Updated title"
  }
}

Delete

Route: DELETE /api/saved_objects/{type}/{id}

cURL: curl -X DELETE http://localhost:5601/api/saved_objects/index-pattern/AVwXs-2htCUMy4H_zXXl

Response: Boolean based on success. We return an error if the document can not be found.

Find

Route: GET /api/saved_objects/{type?}
Query parameters (optional):

• per_page: defaults to 20
• page: defaults to 1
• type: The type in which to limit the results to
• search: Query passed to simple_query_string
• searchFields: Fields to search against
• fields: Fields to return

cURL: curl "http://localhost:5601/api/saved_objects?fields=title&search=tyler"

Response:

{
  "data":[
    {
      "id":"b7aff090-346d-11e7-9d21-53e7c9e02e64",
      "type":"search",
      "version":1,
      "attributes": {
        "title":"s1"
      }
    }
  ],
  "total":1,
  "per_page":20,
  "page":1
}

[simianhacker]

As soon as this is in I will move #10858 over to it.

[jbudz]

tests are failing on this,

 ERROR in ./src/ui/public/saved_objects/index.js
    Module not found: Error: Cannot resolve 'file' or 'directory' ./redirect_when_missing_provider in /var/lib/jenkins/workspace/elastic+kibana+pull-request+multijob-intake/src/ui/public/saved_objects
     @ ./src/ui/public/saved_objects/index.js 34:38-81

[jbudz]

thoughts on removing kibana from the api route? with the goal of eventually opening this api up to all applications

[tylersmalley]

Yeah, I like that.

[jbudz]

cient = client

[jbudz]

This could replace the settings API.

[jbudz]

errors return the underlying query to the browser, thoughts on logging this instead?

[tylersmalley]

Thought on eliminating exposing of the ES query entirely? Logging can be done by enabling elaticsearch.logQueries with --verbose. Logging things like 404's without verbose or an elevated log level seems a little noisy.

[jbudz]

👍

[jbudz]

With types going away, thoughts on allowing saved_objects/{id?} too?

[tylersmalley]

@jbudz, I am all for allowing direct id access to the API but we need to first resolve how we are going to handle the existing conflicts. During the transform, we either need to change the id to be a concatenation of the existing type and id or move everything to UUID's without losing the ability to pull up legacy share URL's

[tylersmalley]

@jbudz, we're now handling version correctly. version is returned with the documents and if you pass version it will fail on a miss-match as expected.

[epixa]

I kind of like the type thing in the URL. Technically id will be unique across types and thus could be used without specifying a type, but what circumstance would that actually be what we want to do when dealing with these specific APIs? The only thing I can think of would be when doing a bulk export of all types or something, but we wouldn't be doing that through these particular APIs anyway.

[spalger]

This is breaking the functional tests somehow... LGTM once they are passing (and not taking an hour to run)

[tylersmalley]

5.x: d2500c3

[spalger]

🎉 🎉 🎉 🎉

[epixa]

Hell yeah!

[stacey-gammon]

sometimes I see fields and sometimes I see searchFields. Which one is correct? Or can both be used?

[tylersmalley]

You should use fields if you want to limit the response. For instance, if you are only interested in title, and description.

searchFields is used in conjunction with search. It allows you to define which fields to search against. Omitting searchFields will search against all fields. You can also define weights, like title^5: https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-simple-query-string-query.html

[nh2]

I've written an export.json CLI importer tool for Kibana that uses this new API: https://github.com/nh2/kibana-importer

With this and the script from #3709 (comment), I can now deploy Kibana in a fully declarative fashion without having to load anything manually into it.

[sandstrom]

This issue is also relevant. If you would prefer a method for loading dashboards and indexpatterns from the file-system (for use with Chef, Puppet, Salt, etc) please vouch for it here:

#2310