# Identifiers
Every item operation has an identifier in its URL. Although this identifier is usually a number, it can also be an `UUID`, a date, or the type of your choice.
To help with your development experience, we introduced an identifier normalization process.
## Custom Identifier Normalizer
> In the following chapter, we're assuming that `App\Uuid` is a project-owned class that manages a time-based UUID.
Let's say you have the following class, which is identified by a `UUID` type. In this example, `UUID` is not a simple string but an object with many attributes.
```php
```
Once registered as an `ApiResource`, having an existing person, it will be accessible through the following URL: `/people/110e8400-e29b-11d4-a716-446655440000`.
Note that the property identifying our resource is named `code`.
Let's create a `DataProvider` for the `Person` entity:
```php
getTimestamp()
}
/**
* {@inheritdoc}
*/
public function supports(string $resourceClass, string $operationName = null, array $context = []): bool
{
return $resourceClass === Person::class;
}
}
```
To cover this use case, we need to `denormalize` the identifier to an instance of our `App\Uuid` class. This case is covered by an identifier denormalizer:
```php
getMessage());
}
}
/**
* {@inheritdoc}
*/
public function supportsDenormalization($data, $type, $format = null)
{
return is_a($type, Uuid::class, true);
}
}
```
Tag this service as an `api_platform.identifier.denormalizer`:
```yaml
services:
App\Identifier\UuidNormalizer:
tags:
- { name: api_platform.identifier.denormalizer }
```
```xml
```
Your `PersonDataProvider` will now work as expected!
## Changing Identifier in a Doctrine Entity
If your resource is also a Doctrine entity and you want to use another identifier other than the Doctrine one, you have to unmark it:
```php