{"_id":"59d04752d014c0001cd4a5a2","project":"568bdc1483d2061900d86cdc","version":{"_id":"59a72290d61777001b6c42c3","project":"568bdc1483d2061900d86cdc","__v":19,"createdAt":"2017-08-30T20:39:44.453Z","releaseDate":"2017-08-30T20:39:44.453Z","categories":["59a7236e3fe4d90025117c10","59a72eb6cb0db3001b84cfe2","59a734eb757d030019b85af8","59c0243b1b2d07001a9d2b76","59c035e42126e10028effb12","59c06c40df5b3c0010584a13","59c1a5852cabe5002641a3e7","59c2fb00b2b45c0010b7a3d7","59c32ceb9aea850010ac4130","59c32e6e190c90003cb0d12f","59c33affb2b45c0010b7aa23","59c7dfa457bd8200105444dc","59c7e975c50cf30010d712a0","59cffdef0cd4dd0010294d54","59d0622ca91a810032c8f60c","59d06733c1aec60026253065","59d174d44ac471001a07b123","59d5a5e323e6e800103defb2","59ecf1d8ed507c001c52b255"],"is_deprecated":false,"is_hidden":false,"is_beta":true,"is_stable":true,"codename":"","version_clean":"0.0.0","version":"0"},"category":{"_id":"59cffdef0cd4dd0010294d54","project":"568bdc1483d2061900d86cdc","version":"59a72290d61777001b6c42c3","__v":0,"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2017-09-30T20:26:23.487Z","from_sync":false,"order":2,"slug":"platform-overview","title":"Platform Overview"},"user":"58cc41f21751ce2f003be3b7","__v":0,"parentDoc":null,"updates":[],"next":{"pages":[],"description":""},"createdAt":"2017-10-01T01:39:30.366Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":3,"body":"# Overview\n\nMetadata is customized information useful to an object, but that is not necessary for the object to function in the Droplit system. Usually, metadata adds information to an object that enables client applications to function. This allows clients to customize their use of the Droplit system without changing its core functionality.\n\nMetadata is usually associated with container objects.\n\nAny object which can support metadata contains a “meta” property. The metadata is considered to be defined if the property is not null. Metadata should be formatted as a valid JSON object. Established metadata can be removed by setting the “meta” property to null.\n\nProperties set through metadata are called keys. Key names follow the same naming rules as IDs and aliases:\n* Between 1 and 24 characters\n* Only contains characters:\n * “a-z”\n * “A-Z”\n * “0-9”\n * “_” (underscore)\n* No spaces\n\n# System-Defined Keys\n\nMetadata keys prefixed with “$” are reserved for special uses. For example, “$label” assigns a display name to an object, and is used by both the developer portal and command line interface tools. It can also be used in client applications.\n\nAPI users can specify other strings to use as a metadata prefix, if desired. Defining a new prefix may be useful when the default metadata prefix, “$label”, already has special meaning in a client application, such as one built with AngularJS.\n\n# Customizing a Metadata Prefix\n\nThe header “x-system-meta-prefix” defines the metadata prefix. This header is not global; that is, using it once will not guarantee that all future metadata is inserted with the desired prefix. Every time new metadata is specified, the prefix must be present in the header in order to be included.\n\nThe prefix is prepended to a metadata key exactly how it is specified in the header, so care should be taken to ensure that the prefix is always consistent. For example, if “x-system-meta-profile” is set to \"droplit-\" for a key called \"$label\", the created key will be “droplit-label”.","excerpt":"","slug":"metadata","type":"basic","title":"Metadata"}
# Overview Metadata is customized information useful to an object, but that is not necessary for the object to function in the Droplit system. Usually, metadata adds information to an object that enables client applications to function. This allows clients to customize their use of the Droplit system without changing its core functionality. Metadata is usually associated with container objects. Any object which can support metadata contains a “meta” property. The metadata is considered to be defined if the property is not null. Metadata should be formatted as a valid JSON object. Established metadata can be removed by setting the “meta” property to null. Properties set through metadata are called keys. Key names follow the same naming rules as IDs and aliases: * Between 1 and 24 characters * Only contains characters: * “a-z” * “A-Z” * “0-9” * “_” (underscore) * No spaces # System-Defined Keys Metadata keys prefixed with “$” are reserved for special uses. For example, “$label” assigns a display name to an object, and is used by both the developer portal and command line interface tools. It can also be used in client applications. API users can specify other strings to use as a metadata prefix, if desired. Defining a new prefix may be useful when the default metadata prefix, “$label”, already has special meaning in a client application, such as one built with AngularJS. # Customizing a Metadata Prefix The header “x-system-meta-prefix” defines the metadata prefix. This header is not global; that is, using it once will not guarantee that all future metadata is inserted with the desired prefix. Every time new metadata is specified, the prefix must be present in the header in order to be included. The prefix is prepended to a metadata key exactly how it is specified in the header, so care should be taken to ensure that the prefix is always consistent. For example, if “x-system-meta-profile” is set to "droplit-" for a key called "$label", the created key will be “droplit-label”.