# What are the constraints for 'id' member?
**URL:** https://discuss.jsonapi.org/t/what-are-the-constraints-for-id-member/380
**Category:** Uncategorized
**Created:** [March 7, 2016, 12:20pm UTC](https://discuss.jsonapi.org/t/what-are-the-constraints-for-id-member/380 "2016-03-07T12:20:13Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@Joana](https://discuss.jsonapi.org/u/Joana)
#### Post date: [March 7, 2016, 12:20pm UTC](https://discuss.jsonapi.org/t/what-are-the-constraints-for-id-member/380/1 "2016-03-07T12:20:13Z")
When our API was implemented we applied the constraints for member names to all members, including id, and everything was good until we had a specific resource which needed a period inside it’s id.
I’ve been carefully reading the specification and on the description of [Resource Objects](http://jsonapi.org/format/#document-resource-objects) [Identification](http://jsonapi.org/format/#document-resource-object-identification) of we have:
> The values of type members **MUST** adhere to the same constraints as [member names](http://jsonapi.org/format/#document-member-names).
And there is referred that:
> To enable an easy mapping of member names to URLs, it is **RECOMMENDED** that member names use only non-reserved, URL safe characters specified in [RFC 3986](http://tools.ietf.org/html/rfc3986).
However I couldn’t find any specific constraints for the id member, can anyone help me?
---
### Author:  [@cd1](https://discuss.jsonapi.org/u/cd1)
#### Post date: [March 7, 2016, 6:31pm UTC](https://discuss.jsonapi.org/t/what-are-the-constraints-for-id-member/380/2 "2016-03-07T18:31:39Z")
Even though there isn’t any spec for the id value, I’d say we should use the same recommendations as for the member names: use only non-reserved, URL safe characters. The ids end up being URLs so they should use the same recommendation.
That’s only my opinion 🙂
---
### Author:  [@Joana](https://discuss.jsonapi.org/u/Joana)
#### Post date: [March 7, 2016, 8:32pm UTC](https://discuss.jsonapi.org/t/what-are-the-constraints-for-id-member/380/3 "2016-03-07T20:32:15Z")
That was also my initial approach…
If we should apply that rule to ‘id’, than we could not have curly brackets on ids, and we have examples using them on [discussion about composite id](http://discuss.jsonapi.org/t/composite-id-inside-the-resource-object/367).
---
### Author:  [@andrewhenderson](https://discuss.jsonapi.org/u/andrewhenderson)
#### Post date: [March 15, 2016, 9:06pm UTC](https://discuss.jsonapi.org/t/what-are-the-constraints-for-id-member/380/4 "2016-03-15T21:06:46Z")
I believe the brackets seen in the discussion you’re referring to are meant to demonstrate that the string represents a variable.
---
### Author:  [@Joana](https://discuss.jsonapi.org/u/Joana)
#### Post date: [March 16, 2016, 9:30am UTC](https://discuss.jsonapi.org/t/what-are-the-constraints-for-id-member/380/5 "2016-03-16T09:30:48Z")
You are probably right, but I wish there was a clear rule for the id.
---
### Author:  [@fdrake](https://discuss.jsonapi.org/u/fdrake)
#### Post date: [December 18, 2019, 6:15pm UTC](https://discuss.jsonapi.org/t/what-are-the-constraints-for-id-member/380/6 "2019-12-18T18:15:08Z")
There doesn’t appear to be anything in the spec that requires “id” values be mapped into URLs, though the examples happen to do so. Is there a need to specify any constraints on the IDs?
For something like the top-level API entry point discussed in [How to handle multiple endpoints/links](https://discuss.jsonapi.org/t/how-to-handle-multiple-endpoints-links/212/3), it even seems reasonable to use an empty string as the ID.