Clarification on allowed characters in id

I wonder whether it is an oversight that all characters are allowed in id’s. Imagine, for example, a second article with “id”: “1/author”. How would this work together with fetching the author corresponding to the article with “id”: “1”?

My motivation for asking is that I do not really understand the reason for supporting a GET request /articles/1/author - isn’t that the same as /articles/1?fields[articles]=author?

Maybe because there are plenty cases where the id is not an int?
/notebook/{id}/note/{id}
/notebook/garden/note/1

“id”: “1/author” is not valid, member names must not have ‘/’ or ‘’ etc.

I may be wrong,
/articles/1/author - isn’t that the same as /articles/1?fields[articles]=author ?
The second version allows only the inclusion of the author field, where the first may include more data on author and article

But the question is about the value of “id”, not the member name, Indeed, the spec says:

The values of `type` members **MUST** adhere to the same constraints as [member names](https://jsonapi.org/format/#document-member-names).

In fact, for me it would probably be much better if an id is allowed to contain slashes.

Why would it be much better? You’re definitely introducing confusion. What makes it worth it?

I admit that I am actually not sure whether I am on the right track. I can only give some background here, you can find the project at https://findstat.org. It currently has no structured API.

I have the following “basic” resources:

  • “Collections”, with identifiers of the form “Cc1234”
  • “Maps”, with identifiers of the form “Mp12345”
  • “Statistics”, with identifiers of the form “St123456”

All of these have some attributes, for example “Description”. “Statistics” and “Maps” also have relationships to “Collections”, for example “Domain” and “Codomain”.

I absolutely do not want to change the above identifiers. In particular, it makes sense to GET such a resource using “Statistics/St123456”.

A user will always have to specify the fields she wants to get, otherwise she only gets “type” and “id”.

Then I have a number of “compound” or “virtual” resources.

  • “CompoundMaps” with identifiers of the form “Mp00020/Mp00101”
  • “CompoundStatistics”, with identifiers of the form “Mp00020/Mp00101/St000005”.

One should be able to GET these using “Statistics/Mp00020/Mp00101/St000005” as a compound document (i.e., not using the endpoint “CompoundStatistics”.)

I realize that this introduces ambiguity: the type of “Statistics/St000005” is “Statistics”, although one might think it is “CompoundStatistics”. (Maybe I should rename “Statistics” to “BasicStatistics” and “CompoundStatistics” to “Statistics”…)

I thought I would represent “CompoundStatistics” as follows:

{
  "type":"CompoundStatistics",
  "id":"Mp00020/Mp00101/St000005",
  "attributes":{
    "Values":"[.,.] => [1,0] => [1,0] => 0\n[.,[.,.]] => [1,1,0,0] => [1,0,1,0] => 1\n[[.,.],.] => [1,0,1,0] => [1,1,0,0] => 0\n...",
    "Distribution":{
      "1":{
        "0":1
      },
      "2":{
        "0":1,
        "1":1
      }
    }
  },
  "relationships":{
    "Maps":{
      "data":[
        {
          "type":"Maps",
          "id":"Mp00020"
        },
        {
          "type":"Maps",
          "id":"Mp00101"
        }
      ]
    }
  },
  "Statistic":{
    "data":{
      "type":"Statistics",
      "id":"St000005"
    }
  }
}

I dislike the “relationships” member quite a bit, it is and should be completely redundant.
It exists only because of the full-linkage requirement.

  • “MatchingStatistics”, whose identifier will possibly be an identifier of a “CompoundStatistic” together with a running index, not sure about that yet.