Polymorphic relations about json-api

[paddycarver]

I'm still not convinced there are truly polymorphic types. In the case of 2, I'd say that it's a resource of type Author, which can point to a resource of type User or type Company. E.g.

{
  "authors": [
    {
      "id": 1,
      "type": "users",
      "foreign_id": 3
    }
  ]
}

Author 1 corresponds to User 3, yes, but they're still separate resources. In my mind, a type is something that you can interact with uniformly regardless of the data it holds. With an Author type, you can always retrieve an Author, create an Author, delete an Author, get an Author's posts, and it doesn't matter whether the Author is a Person or a Company. Type-safety makes life sane for static languages.

[indirect]

And in case 1? Should that also be "type": "users"? Seems like the only way to know to grab the users key from the URL (especially in ID format, where convention dictates that you request /authors/1).

[paddycarver]

I was under the impression that was a different issue. Aliasing vs. polymorphism, as it were.

Personally, the solution I'd arrive at would be to meta: { model: "users" }, but if you have a better proposal, I'm all for that. I've largely managed to sidestep this issue in the past by structuring my fields to use the model_id key, but I know there are some instances where this isn't possible. I just don't have a strong opinion either way on it, which is why I didn't reply to that specific point.

The polymorphism I do have a strong opinion on, because it has caused me no small amount of grief in the past.

[indirect]

Just to make sure I'm clear, your answer is "there is no polymorphic association, only associations through a non-polymorphic join object"?

[paddycarver]

I'm having trouble parsing your statement. Tentatively, I think that is what I am saying.

To put it another way, I've yet to come across a resource I can't express in a statically-typed, non-polymorphic way. Where every key corresponds to one, and only one, concrete type. In the event that that concrete type is subscriptable (e.g., it has keys with their own values, or is an array), I've never experienced any situation in which that type did not always have the same set of keys (with some of them being optional, on occasion), each with their own consistent set of typed values.

E.g., if posts[0].author.name exists for one post, it exists and is the same type for all posts. Once I define my expectation that a post will consist of a certain set of fields, every future post will conform to those fields.

Perhaps my experience is limited, but I've never found a situation where that was not possible. And in some languages (primarily the statically-typed ones) it is either impossible, unsafe, or unbearably slower to implement clients for APIs that do not conform to that principle, which is why I harp on it so. It's a truly painful experience to work with APIs that do not follow that simple principle: if I expect a string, you are not going to give me an int.

[steveklabnik]

Polymorphic types are out, due to comments made in other threads.

"alias types" are the same problem, hence being in the same ticket: If you directly expose your business objects, you're gonna have a bad time. Expose what your API needs to expose, and handle this kind of 'aliasing' internally.