{"_id":"5a8fae0468264c001f20cc35","category":{"_id":"5a8fae0368264c001f20cc04","version":"5a8fae0268264c001f20cc00","project":"5633ebff7e9e880d00af1a53","__v":0,"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-05-31T04:26:39.925Z","from_sync":false,"order":5,"slug":"versions","title":"Bonsai.io Platform"},"parentDoc":null,"user":"5637d336aa96490d00a64f81","project":"5633ebff7e9e880d00af1a53","version":{"_id":"5a8fae0268264c001f20cc00","project":"5633ebff7e9e880d00af1a53","__v":4,"createdAt":"2018-02-23T06:00:34.961Z","releaseDate":"2018-02-23T06:00:34.961Z","categories":["5a8fae0268264c001f20cc01","5a8fae0268264c001f20cc02","5a8fae0368264c001f20cc03","5a8fae0368264c001f20cc04","5a8fae0368264c001f20cc05","5a8fae0368264c001f20cc06","5a8fae0368264c001f20cc07","5a8fae0368264c001f20cc08","5a8fae0368264c001f20cc09","5abaa7eb72d6dc0028a07bf3","5b8ee7842790f8000333f9ba","5b8ee8f244a21a00034b5cd9"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"2.0.0","version":"2.0"},"githubsync":"","__v":0,"updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-03-09T01:11:52.880Z","link_external":false,"link_url":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":8,"body":"Bonsai clusters support most Elasticsearch APIs out of the box, with a few exceptions. This article details those exceptions, along with a brief explanation of why they're in place. \n\nWhile having many of the following endpoints can be helpful for power users, the majority of applications don't directly need them. If, however, you find yourself stuck without one of these available, please [email us](mailto:support:::at:::bonsai.io) and we'll be happy to help.\n[block:api-header]\n{\n  \"title\": \"_all and wildcard destructive actions\"\n}\n[/block]\nWildcard delete actions are usually for clusters with a large number of indices, and can be useful for completely wiping out a cluster and starting over. Wildcard and _all destructive actions were initially available on shared tier clusters. However, we received an increasingly large number of threads from distressed developers that accidentally deleted their entire production clusters.\n\nAfter some internal discussion, we decided to disable wildcard actions. Removing the ability to sweepingly delete everything forces users to slow down and identify exactly what they're deleting, reducing the risk of accidental and permanent data loss. \n\nExamples of _all and wildcard destruction:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"DELETE /*\\nDELETE /_all\",\n      \"language\": \"text\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Node hot threads\"\n}\n[/block]\nA Java thread that uses lots of CPU and runs for an unusually long period of time is known as a _hot thread_. Elasticsearch provides an API to get the current hot threads on each node in the cluster. This information can be useful in forming a holistic picture of potential problems within the cluster.  \n\nBonsai doesn't support these endpoints on our shared tier to ensure user activity isn't exposed to others. For a detailed explanation of why this is a concern, please see the article on [Architecture Classes](doc:architecture-classes). Additionally, Bonsai is a managed service, so it's really the responsibility of our Ops Team to investigate node-level issues.\n\nIf you think there is a problem with your cluster that you need help troubleshooting, please [email support](mailto:support@bonsai.io).\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"    GET /_cluster/nodes/hotthreads\\n    GET /_cluster/nodes/hot_threads\\n    GET /_cluster/nodes/{nodeId}/hotthreads\\n    GET /_cluster/nodes/{nodeId}/hot_threads\\n    GET /_nodes/hotthreads\\n    GET /_nodes/hot_threads\\n    GET /_nodes/{nodeId}/hotthreads\\n    GET /_nodes/{nodeId}/hot_threads\",\n      \"language\": \"text\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Node Shutdown & Restart\"\n}\n[/block]\nElasticsearch provides an API for shutting down and restarting nodes. This functionality is unsupported across the platform. On our [multitenant architecture](doc:architecture-classes#multi-tenant-class), this prevents a user from shutting down a node or set of nodes that may be in use by another user. That action would have an adverse affect on other users which is why it is unsupported. This also prevents users from exacerbating whatever problem they're trying to resolve.\n\nIf you think there is a problem with your cluster that you need help troubleshooting, please [email support](mailto:support@bonsai.io).\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"    POST /_cluster/nodes/_restart\\n    POST /_cluster/nodes/_shutdown\\n    POST /_cluster/nodes/{nodeId}/_restart\\n    POST /_cluster/nodes/{nodeId}/_shutdown\\n    POST /_shutdown\",\n      \"language\": \"text\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Snapshots\"\n}\n[/block]\nThe Snapshot API allows users to create and restore snapshots of indices and cluster data. It's useful as a backup tool and for recovering from problems or data loss. On Bonsai, we're [already taking regular snapshots](doc:how-bonsai-manages-snapshots) and monitoring cluster states for problems,. This API is blocked to avoid problems associated with multiple users trying to snapshot/restore at once. \n\nIf you feel that you need a snapshot taken/restored, please reach out to our [support team](mailto:support@bonsai.io).\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"    GET    /_snapshot/_status\\n    DELETE /_snapshot/{repository}\\n    POST   /_snapshot/{repository}\\n    PUT    /_snapshot/{repository}\\n    GET    /_snapshot/{repository}/_status\\n    DELETE /_snapshot/{repository}/{snapshot}\\n    GET    /_snapshot/{repository}/{snapshot}\\n    POST   /_snapshot/{repository}/{snapshot}\\n    PUT    /_snapshot/{repository}/{snapshot}\\n    POST   /_snapshot/{repository}/{snapshot}/_create\\n    PUT    /_snapshot/{repository}/{snapshot}/_create\\n    POST   /_snapshot/{repository}/{snapshot}/_restore\\n    GET    /_snapshot/{repository}/{snapshot}/_status\",\n      \"language\": \"text\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Reindex\"\n}\n[/block]\nThe [Reindex API](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-reindex.html) essentially copies documents from one index to another. For example, it will copy documents from an index called `books` into another index, like `new_books`. It [does this](https://github.com/elastic/elasticsearch/blob/master/modules/reindex/src/main/java/org/elasticsearch/index/reindex/RestReindexAction.java) by using what is basically a [scan and scroll search](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-scroll.html), reading the contents of one index into another. The API call looks something like this:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"    POST /_reindex\",\n      \"language\": \"text\"\n    }\n  ]\n}\n[/block]\nThe Reindex API is still an experimental tool, and not supported on Bonsai at this time. It can be extremely demanding on IO, which can impact performance and availability for other users. While there are some parameters which can throttle the process, our preliminary tests still found that it's a liability on [multitenant architectures](doc:architecture-classes).\n\nOne workaround is to set up an indexing script that uses the scan and scroll search to read documents from your old index and push them into the new index. For example, read the contents of `GET /my_index/_search?search_type=scan&scroll=1m`, then `POST` those retrieved docs into a new index. That would provide basically the same functionality.\n\nAnother option is to simply populate the new index directly from your database.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Cluster Shard Reroute\"\n}\n[/block]\nElasticsearch provides an API to move shards around between nodes within a cluster. We don't support this functionality on our shared plans for a few reasons. For one it interferes with our cluster management tooling, and there is a possibility for one or more users to allocate shards in a way that overloads a node.\n\nIf you need fine-grain control over the shard allocation within a cluster, please [reach out to us](mailto:support@bonsai.io) and we can discuss your use case and look at whether single tenancy would be a good fit for you.\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"    POST /_cluster/reroute\",\n      \"language\": \"text\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Cluster settings\"\n}\n[/block]\nElasticsearch provides an API to apply cluster-wide settings. We don't support this in our [shared environment](doc:architecture-classes#multi-tenant-class) for safety reasons. In an environment where system resources are shared, this API would affect all users simultaneously. So one user could affect the behavior of everyone's cluster in ways that those users may not want. Instead, we block this API and remain opinionated about cluster settings.\n\nIf you need to change the system settings for your cluster, you'll need to be in a single tenant environment. [Reach out to us](mailto:support@bonsai.io) and let's talk through it.\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"    PUT /_cluster/settings\",\n      \"language\": \"text\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Index Optimize / Forcemerge\"\n}\n[/block]\nLucene (the underlying search software that powers Elasticsearch) stores data across an array of files known as segment files. As new data is created, Lucene creates new files. The overhead of managing multiple files and performing binary search across the segments is trivial compared to the overhead of constantly updating and re-sorting a small number of files.\n\nLucene will periodically merge the segment files when certain criteria are met; this speeds up search by reducing the amount of data to be parsed. Elasticsearch provides an API to force this process to happen on demand, which is useful in certain situations (like when data is filling up a node).\n\nWe don't support this on our [shared clusters](doc:architecture-classes#multi-tenant-class) for a couple of reasons. For one, it is extremely expensive in terms of system resources, and there would be nothing stopping a user from optimizing their indices on every update or every 60s, etc. A single user could adversely impact every user sharing resources. Optimizing an index is also a blocking operation, which means it could interfere with our internal cluster management tools.\n\nIf you feel like your cluster needs this ability, [hit us up](mailto:support@bonsai.io) and let's chat about it.\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"    # 2.x and earlier\\n    GET  /_optimize\\n    POST /_optimize\\n    GET  /{index}/_optimize\\n    POST /{index}/_optimize\\n    \\n    # 5.x and later\\n    GET  /_forcemerge\\n    POST /_forcemerge\\n    GET  /{index}/_forcemerge\\n    POST /{index}/_forcemerge\",\n      \"language\": \"text\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Index Search Warmers\"\n}\n[/block]\nElasticsearch provides a mechanism to speed up searches prior to being run. It does this by basically pre-populating caches via automatically running search requests. This is called \"warming\" the data, and it's typically done against searches that require heavy system resources.\n\nWe don't support this on [shared clusters](doc:architecture-classes#multi-tenant-class) for stability reasons. Essentially there isn't a great way to throttle the impact of an arbitrary number of warmers. There is a possibility that a user could overwhelm the system resources by creating a large number of \"heavy\" warmers (aggregations, sorts on large lists, etc). It's also somewhat of an anti-pattern in a [multitenant environment](doc:architecture-classes).\n\nIf this is something critical to your app, you would need to be on a dedicated cluster. Please [reach out to us](mailto:support@bonsai.io) if you have any further questions on this.\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"    POST /_warmer/{name}\\n    PUT  /_warmer/{name}\\n    POST /_warmers/{name}\\n    PUT  /_warmers/{name}\\n    POST /{index}/_warmer/{name}\\n    PUT  /{index}/_warmer/{name}\\n    POST /{index}/_warmers/{name}\\n    PUT  /{index}/_warmers/{name}\\n    POST /{index}/{type}/_warmer/{name}\\n    PUT  /{index}/{type}/_warmer/{name}\\n    POST /{index}/{type}/_warmers/{name}\\n    PUT  /{index}/{type}/_warmers/{name}\",\n      \"language\": \"text\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Static Scripts\"\n}\n[/block]\nElasticsearch provides an API for adding and modifying static scripts to a cluster. We don't support this on [shared clusters](doc:architecture-classes#multi-tenant-class), both for security reasons as well as the fact that we're opinionated about scripting language. \n\nDue to some pretty serious vulnerabilities in the Groovy scripting language, we default to Lucene Expressions. Users are able to take advantage of [inline scripting](https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-scripting-using.html) using [Lucene Expressions](https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-scripting-expression.html).\n\nIf you need to configure static scripts or using a language other than Expressions, [let us know](mailto:support@bonsai.io) and we can get you set up with a [single tenant](doc:architecture-classes#single-tenant-class) cluster.\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"    DELETE /_scripts/{lang}/{id}\\n    GET    /_scripts/{lang}/{id}\\n    POST   /_scripts/{lang}/{id}\\n    PUT    /_scripts/{lang}/{id}\\n    POST   /_scripts/{lang}/{id}/_create\\n    PUT    /_scripts/{lang}/{id}/_create\",\n      \"language\": \"text\"\n    }\n  ]\n}\n[/block]","excerpt":"","slug":"bonsai-unsupported-actions","type":"basic","title":"Unsupported API Endpoints"}

Unsupported API Endpoints


Bonsai clusters support most Elasticsearch APIs out of the box, with a few exceptions. This article details those exceptions, along with a brief explanation of why they're in place. While having many of the following endpoints can be helpful for power users, the majority of applications don't directly need them. If, however, you find yourself stuck without one of these available, please [email us](mailto:support@bonsai.io) and we'll be happy to help. [block:api-header] { "title": "_all and wildcard destructive actions" } [/block] Wildcard delete actions are usually for clusters with a large number of indices, and can be useful for completely wiping out a cluster and starting over. Wildcard and _all destructive actions were initially available on shared tier clusters. However, we received an increasingly large number of threads from distressed developers that accidentally deleted their entire production clusters. After some internal discussion, we decided to disable wildcard actions. Removing the ability to sweepingly delete everything forces users to slow down and identify exactly what they're deleting, reducing the risk of accidental and permanent data loss. Examples of _all and wildcard destruction: [block:code] { "codes": [ { "code": "DELETE /*\nDELETE /_all", "language": "text" } ] } [/block] [block:api-header] { "type": "basic", "title": "Node hot threads" } [/block] A Java thread that uses lots of CPU and runs for an unusually long period of time is known as a _hot thread_. Elasticsearch provides an API to get the current hot threads on each node in the cluster. This information can be useful in forming a holistic picture of potential problems within the cluster. Bonsai doesn't support these endpoints on our shared tier to ensure user activity isn't exposed to others. For a detailed explanation of why this is a concern, please see the article on [Architecture Classes](doc:architecture-classes). Additionally, Bonsai is a managed service, so it's really the responsibility of our Ops Team to investigate node-level issues. If you think there is a problem with your cluster that you need help troubleshooting, please [email support](mailto:support@bonsai.io). [block:code] { "codes": [ { "code": " GET /_cluster/nodes/hotthreads\n GET /_cluster/nodes/hot_threads\n GET /_cluster/nodes/{nodeId}/hotthreads\n GET /_cluster/nodes/{nodeId}/hot_threads\n GET /_nodes/hotthreads\n GET /_nodes/hot_threads\n GET /_nodes/{nodeId}/hotthreads\n GET /_nodes/{nodeId}/hot_threads", "language": "text" } ] } [/block] [block:api-header] { "type": "basic", "title": "Node Shutdown & Restart" } [/block] Elasticsearch provides an API for shutting down and restarting nodes. This functionality is unsupported across the platform. On our [multitenant architecture](doc:architecture-classes#multi-tenant-class), this prevents a user from shutting down a node or set of nodes that may be in use by another user. That action would have an adverse affect on other users which is why it is unsupported. This also prevents users from exacerbating whatever problem they're trying to resolve. If you think there is a problem with your cluster that you need help troubleshooting, please [email support](mailto:support@bonsai.io). [block:code] { "codes": [ { "code": " POST /_cluster/nodes/_restart\n POST /_cluster/nodes/_shutdown\n POST /_cluster/nodes/{nodeId}/_restart\n POST /_cluster/nodes/{nodeId}/_shutdown\n POST /_shutdown", "language": "text" } ] } [/block] [block:api-header] { "type": "basic", "title": "Snapshots" } [/block] The Snapshot API allows users to create and restore snapshots of indices and cluster data. It's useful as a backup tool and for recovering from problems or data loss. On Bonsai, we're [already taking regular snapshots](doc:how-bonsai-manages-snapshots) and monitoring cluster states for problems,. This API is blocked to avoid problems associated with multiple users trying to snapshot/restore at once. If you feel that you need a snapshot taken/restored, please reach out to our [support team](mailto:support@bonsai.io). [block:code] { "codes": [ { "code": " GET /_snapshot/_status\n DELETE /_snapshot/{repository}\n POST /_snapshot/{repository}\n PUT /_snapshot/{repository}\n GET /_snapshot/{repository}/_status\n DELETE /_snapshot/{repository}/{snapshot}\n GET /_snapshot/{repository}/{snapshot}\n POST /_snapshot/{repository}/{snapshot}\n PUT /_snapshot/{repository}/{snapshot}\n POST /_snapshot/{repository}/{snapshot}/_create\n PUT /_snapshot/{repository}/{snapshot}/_create\n POST /_snapshot/{repository}/{snapshot}/_restore\n GET /_snapshot/{repository}/{snapshot}/_status", "language": "text" } ] } [/block] [block:api-header] { "type": "basic", "title": "Reindex" } [/block] The [Reindex API](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-reindex.html) essentially copies documents from one index to another. For example, it will copy documents from an index called `books` into another index, like `new_books`. It [does this](https://github.com/elastic/elasticsearch/blob/master/modules/reindex/src/main/java/org/elasticsearch/index/reindex/RestReindexAction.java) by using what is basically a [scan and scroll search](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-scroll.html), reading the contents of one index into another. The API call looks something like this: [block:code] { "codes": [ { "code": " POST /_reindex", "language": "text" } ] } [/block] The Reindex API is still an experimental tool, and not supported on Bonsai at this time. It can be extremely demanding on IO, which can impact performance and availability for other users. While there are some parameters which can throttle the process, our preliminary tests still found that it's a liability on [multitenant architectures](doc:architecture-classes). One workaround is to set up an indexing script that uses the scan and scroll search to read documents from your old index and push them into the new index. For example, read the contents of `GET /my_index/_search?search_type=scan&scroll=1m`, then `POST` those retrieved docs into a new index. That would provide basically the same functionality. Another option is to simply populate the new index directly from your database. [block:api-header] { "type": "basic", "title": "Cluster Shard Reroute" } [/block] Elasticsearch provides an API to move shards around between nodes within a cluster. We don't support this functionality on our shared plans for a few reasons. For one it interferes with our cluster management tooling, and there is a possibility for one or more users to allocate shards in a way that overloads a node. If you need fine-grain control over the shard allocation within a cluster, please [reach out to us](mailto:support@bonsai.io) and we can discuss your use case and look at whether single tenancy would be a good fit for you. [block:code] { "codes": [ { "code": " POST /_cluster/reroute", "language": "text" } ] } [/block] [block:api-header] { "type": "basic", "title": "Cluster settings" } [/block] Elasticsearch provides an API to apply cluster-wide settings. We don't support this in our [shared environment](doc:architecture-classes#multi-tenant-class) for safety reasons. In an environment where system resources are shared, this API would affect all users simultaneously. So one user could affect the behavior of everyone's cluster in ways that those users may not want. Instead, we block this API and remain opinionated about cluster settings. If you need to change the system settings for your cluster, you'll need to be in a single tenant environment. [Reach out to us](mailto:support@bonsai.io) and let's talk through it. [block:code] { "codes": [ { "code": " PUT /_cluster/settings", "language": "text" } ] } [/block] [block:api-header] { "type": "basic", "title": "Index Optimize / Forcemerge" } [/block] Lucene (the underlying search software that powers Elasticsearch) stores data across an array of files known as segment files. As new data is created, Lucene creates new files. The overhead of managing multiple files and performing binary search across the segments is trivial compared to the overhead of constantly updating and re-sorting a small number of files. Lucene will periodically merge the segment files when certain criteria are met; this speeds up search by reducing the amount of data to be parsed. Elasticsearch provides an API to force this process to happen on demand, which is useful in certain situations (like when data is filling up a node). We don't support this on our [shared clusters](doc:architecture-classes#multi-tenant-class) for a couple of reasons. For one, it is extremely expensive in terms of system resources, and there would be nothing stopping a user from optimizing their indices on every update or every 60s, etc. A single user could adversely impact every user sharing resources. Optimizing an index is also a blocking operation, which means it could interfere with our internal cluster management tools. If you feel like your cluster needs this ability, [hit us up](mailto:support@bonsai.io) and let's chat about it. [block:code] { "codes": [ { "code": " # 2.x and earlier\n GET /_optimize\n POST /_optimize\n GET /{index}/_optimize\n POST /{index}/_optimize\n \n # 5.x and later\n GET /_forcemerge\n POST /_forcemerge\n GET /{index}/_forcemerge\n POST /{index}/_forcemerge", "language": "text" } ] } [/block] [block:api-header] { "type": "basic", "title": "Index Search Warmers" } [/block] Elasticsearch provides a mechanism to speed up searches prior to being run. It does this by basically pre-populating caches via automatically running search requests. This is called "warming" the data, and it's typically done against searches that require heavy system resources. We don't support this on [shared clusters](doc:architecture-classes#multi-tenant-class) for stability reasons. Essentially there isn't a great way to throttle the impact of an arbitrary number of warmers. There is a possibility that a user could overwhelm the system resources by creating a large number of "heavy" warmers (aggregations, sorts on large lists, etc). It's also somewhat of an anti-pattern in a [multitenant environment](doc:architecture-classes). If this is something critical to your app, you would need to be on a dedicated cluster. Please [reach out to us](mailto:support@bonsai.io) if you have any further questions on this. [block:code] { "codes": [ { "code": " POST /_warmer/{name}\n PUT /_warmer/{name}\n POST /_warmers/{name}\n PUT /_warmers/{name}\n POST /{index}/_warmer/{name}\n PUT /{index}/_warmer/{name}\n POST /{index}/_warmers/{name}\n PUT /{index}/_warmers/{name}\n POST /{index}/{type}/_warmer/{name}\n PUT /{index}/{type}/_warmer/{name}\n POST /{index}/{type}/_warmers/{name}\n PUT /{index}/{type}/_warmers/{name}", "language": "text" } ] } [/block] [block:api-header] { "type": "basic", "title": "Static Scripts" } [/block] Elasticsearch provides an API for adding and modifying static scripts to a cluster. We don't support this on [shared clusters](doc:architecture-classes#multi-tenant-class), both for security reasons as well as the fact that we're opinionated about scripting language. Due to some pretty serious vulnerabilities in the Groovy scripting language, we default to Lucene Expressions. Users are able to take advantage of [inline scripting](https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-scripting-using.html) using [Lucene Expressions](https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-scripting-expression.html). If you need to configure static scripts or using a language other than Expressions, [let us know](mailto:support@bonsai.io) and we can get you set up with a [single tenant](doc:architecture-classes#single-tenant-class) cluster. [block:code] { "codes": [ { "code": " DELETE /_scripts/{lang}/{id}\n GET /_scripts/{lang}/{id}\n POST /_scripts/{lang}/{id}\n PUT /_scripts/{lang}/{id}\n POST /_scripts/{lang}/{id}/_create\n PUT /_scripts/{lang}/{id}/_create", "language": "text" } ] } [/block]