What are the constraints for 'id' member?

1

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 Identification of we have:

The values of type members MUST adhere to the same constraints as 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.

However I couldn’t find any specific constraints for the id member, can anyone help me?

2

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 :slight_smile:

3

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.

4

I believe the brackets seen in the discussion you’re referring to are meant to demonstrate that the string represents a variable.

5

You are probably right, but I wish there was a clear rule for the id.

6

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, it even seems reasonable to use an empty string as the ID.