Let's register a resource with the label `sample` by `INIT_PEER_ID`:
```rust
func my_resource() -> ?ResourceId, *Error:
id, errors <-createResource("sample")
<-id,errors
```
-`label` is a unique string for the peer id
- creation is successful if a resource id is returned
-`*Error` accumulates errors from all the affected peers
## How to remove a Resource
For now there is no method for Resource removal but it can be expired and garbage-collected if it doesn't have any actual records. In the future updates it can be changed.
- it is a combination of `resolveResource` and a `for` loop through records with the callback execution
- it can be useful in case of broadcasting events
## Replication
Resources with corresponding records and tombstones are automatically and periodically replicated to the Kademlia neighborhood of `resource_id`.
## Remarks
You can redefine [`INITIAL_REPLICATION_FACTOR`](https://github.com/fluencelabs/registry/blob/main/aqua/resources-api.aqua#L10) and [`CONSISTENCY_LEVEL`](https://github.com/fluencelabs/registry/blob/main/aqua/resources-api.aqua#L11). The first constant is used to define the number of peers to which data will be replicated during the API call. This constant doesn't affect the network-wide replication factor, which is defined by Kademlia. The second constant defines the minimal number of peers requested to obtain the data.
## Use cases
### Services discovery
Discover services without prior knowledge about exact peers and service identifiers.
### Service high-availability
A service provided by several peers still will be available for the client in case of disconnections and other providers' failures.

### Subnetwork discovery
You can register a group of peers for a resource (without specifying any services). So you "tag" and group the nodes to create a subnetwork.

### Load balancer
If you have a list of service records updated in runtime, you can create a load-balancing service based on your preferred metrics.