Compound Resource IDs versus URL IDs - json-api

Question

I have two resources with a strict parent/child hierarchical relationship, where the child has no existence without the parent, and where the child ID must be a monotonically increasing integer starting from 1 within the parent resource, so not unique within the global resource set. Lets call them Foo and Bar, where Foo is the parent:
Foo: ABC
|- Bar: 1
|- Bar: 2
|- Bar: 3
Foo: QWE
|- Bar: 1
|- Bar: 2
Within the database, we store this in a table with a simple compound natural key:
Foo | Bar | Value
===================
ABC | 1 | shizzle
ABC | 2 | bizzle
ABC | 3 | fizzle
QWE | 1 | lorem
QWE | 2 | ipsum
The standard requires that the Type / ID combination must be unique within the api to allow included resources to be correctly linked to, so to create a unique Bar ID here we would have to join the compound key as say Foo_Bar, i.e. ABC_1 and QWE_1. Ugly and bringing some issues around the client needing to have knowledge of the key composition and the joining char, but fair enough, and we can always add the natural key as either data or meta for the client to use instead.
My question comes with the url for the child resource. For internal consistency with the document ID, the url might look like:
https://example.com/api/v1/foos/ABC/bars/ABC_1
but that seems rather redundant repeating the 'ABC', not to mention ugly, and inconsistent with our main website urls. I'd much prefer using:
https://example.com/api/v1/foos/ABC/bars/1
I think I'm free to do what I want, but I suspect this may cause issues for some of the libraries out there if they make the assumption that they are the same? In general are urls required to have any logical relationship to the internal Resource Type/ID?
Related to this, can the Resource ID use a '.' to join the composite key instead of a '_'? This would make it consistent wth the relationship paths, so 'foos.bars' = 'ABC.1'. While the standard prohibits '.' in member names, there seems to be no such constraint on ID names?
Cheers!
John.

Answer 1

The specification is not absolute on the format url. Thought it recommends that urls match the resource's id.
From http://jsonapi.org/recommendations/#urls-individual-resources
Treat collections of resources as sets keyed by resource ID. The URL for an individual resource can be formed by appending the resource’s ID to the collection URL.
For example, a photo with an ID of "1" will have the URL:
/photos/1
Following this, your url to access the foo resource with id ABC_1 would be
https://example.com/api/v1/foos/ABC_1
and accordingly to get the bar resource with id 1
https://example.com/api/v1/bars/1
Regarding your example url https://example.com/api/v1/foos/ABC/bars/ABC_1, while not invalid, you won't find any similar example in the specification similar to resource_type/resource_id/relation_name/relation_id (with 4 nested levels).
The specification recommendation is to have 3 levels, which will return in your case an array of resource identifier objects:
resource_type/resource_id/relation_name
From http://jsonapi.org/recommendations/#urls-relationships
It is recommended that a relationship URL be formed by appending /relationships/ and the name of the relationship to the resource’s URL.
For example, a photo’s comments relationship will have the URL:
/photos/1/relationships/comments