Managing knowledge objects
This section shows some typical use cases for managing objects in the REST API. Use these examples to learn how to perform operations such as moving an object to a different app or changing the permissions of an object.
You can also use the servicesNS endpoints to access resources within a user/app context called the namespace. For more information about using namespaces, see Namespace in the REST API User Manual.
Create a new object for a specific context
Create a saved search for the user Alice that is available from the app, myapp. This saved search is private to Alice.
curl -k -u alice:pass https://localhost:8089/servicesNS/alice/myapp/saved/searches/ \ -d name=mysearch \ -d search=*
Edit an object
Change the above search created for Alice.
Because this search is private to Alice, she can edit the search.
curl -k -u alice:pass https://localhost:8089/servicesNS/alice/myapp/saved/searches/mysearch \ -d search="index=mai*"
In general, use the REST handler associated with a knowledge object to programmatically modify it. The search macros and transactions types of knowledge objects, however, do not have an associated REST handler. For these types of knowledge objects, modify them by manipulating the configuration file directly with the /configs
endpoint. For more information about the /configs
endpoint, see Configuration endpoint descriptions in the REST API Reference Manual.
In either case, modify permissions for knowledge objects with the Access Control List (ACL) endpoints. For more information about the ACL endpoints, see Access Control List in the REST API User Manual.
Consult the following table to determine which method to use for each type of knowledge object. For detailed descriptions of each endpoint, see the REST API Reference Manual.
Knowledge object type | Modification method | REST API endpoint |
---|---|---|
Data models | REST handler | /datamodel/model/{name} |
Event types | REST handler | /saved/eventtypes/{name} |
Field extractions | REST handler | /data/transforms/extractions/ or /data/props/extractions/{name} |
Fields | REST handler | /search/fields/{name} |
Lookups | REST handler | /data/props/lookups/{name} |
Navigation | REST handler | /services/directory/{name} |
Panels | REST handler | /data/ui/panels |
Saved searches | REST handler | /saved/searches/{name} |
Search macros | configuration file | /services/configs/conf-macros/{name} |
Tags | REST handler | /search/tags/ |
Transactions | configuration file | /services/configs/conf-transactiontypes/{name} |
Views | REST handler | /data/ui/views |
Modify an object's permissions with the REST handler
For example, you can make Alice's saved search, mysearch, available through the app, myapp, by using the saved/searches/mysearch REST handler. The following command grants all users permissions to read the saved search.
curl -k -u admin:pass https://localhost:8089/servicesNS/alice/myapp/saved/searches/mysearch/acl \ -d perms.read=* \ -d owner=alice \ -d sharing=app
Edit the search at the shared location. Because the search is now a shared resource, use <nobody> for the <user> context.
curl -k -u alice:pass https://localhost:8089/servicesNS/nobody/myapp/saved/searches/mysearch \ -d search="index=main"
Modify an object's permissions by editing configuration files
Similarly, you can make Bob's macro, mymacro, available globally by editing the macros configuration file. The following command shares mymacro globally and grants write permissions for admin and power roles.
curl -k -u bob:pass https://localhost:8089/services/configs/conf-macros/mymacro/acl -d "sharing=global&owner=nobody"
After you run the command, the macro is available in the main search app.
The following command modifies permissions so that mymacro can still be read by everyone, but is owned and can be written only by users with the admin role.
curl -k -u bob:pass https://localhost:8089/services/configs/conf-macros/mymacro/acl -d "perms.read=*&perms.write=admin&owner=admin&sharing=global"
Move an object to a different app
The saved search that was previously available to all in the context of myapp is now only available in the context of otherapp.
curl -k -u admin:pass https://localhost:8089/servicesNS/nobody/myapp/saved/searches/mysearch/move \ -d user=nobody \ -d app=otherapp
Access objects available in all user/app contexts
Using wildcards, access all saved searches that you have permission to view.
For an admin user, this includes other user's private saved searches.
For a non-admin user, you retrieve only saved searches you have permission to view.
curl -k -u admin:pass https://localhost:8089/servicesNS/-/-/saved/searches curl -k -u alice:pw https://localhost:8089/servicesNS/-/-/saved/searches
Access requirements and limitations for the Splunk Cloud Platform REST API | Accessing and updating Splunk Enterprise configurations |
This documentation applies to the following versions of Splunk® Enterprise: 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.0.9, 7.0.10, 7.0.11, 7.0.13, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.1.8, 7.1.9, 7.1.10, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6, 7.2.7, 7.2.8, 7.2.9, 7.2.10, 7.3.0, 7.3.1, 7.3.2, 7.3.3, 7.3.4, 7.3.5, 7.3.6, 7.3.7, 7.3.8, 7.3.9, 8.0.0, 8.0.1, 8.0.2, 8.0.3, 8.0.4, 8.0.5, 8.0.6, 8.0.7, 8.0.8, 8.0.9, 8.0.10, 8.1.1, 8.1.2, 8.1.3, 8.1.4, 8.1.5, 8.1.6, 8.1.7, 8.1.8, 8.1.9, 8.1.13, 8.1.14, 8.2.0, 8.2.1, 8.2.2, 8.2.3, 8.2.4, 8.2.5, 8.2.6, 8.2.7, 8.2.8, 8.2.9, 8.2.10, 8.2.11, 8.2.12, 9.0.0, 9.0.1, 9.0.2, 9.0.3, 9.0.4, 9.0.5, 9.0.6, 9.0.7, 9.0.8, 9.0.9, 9.0.10, 9.1.0, 9.1.1, 9.1.2, 9.1.3, 9.1.4, 9.1.5, 9.1.6, 9.2.0, 9.2.1, 9.2.2, 9.2.3, 9.3.0, 9.3.1, 8.1.0, 8.1.10, 8.1.11, 8.1.12
Feedback submitted, thanks!