Karsten Nikolai Strand

It wouldn't directly be the C# specific System.Type. There's already a type mapping set up, and that would be used regardless of whether the entity type is specified in the...

There's also another consideration: inheritance. To keep backwards compatibility I'm also thinking it might be a good idea to make the type specifier an array instead of a string. Take...

@asbjornu, I find using the full media type inside the document awkward and too verbose. Could you describe a specific real life scenario where this would be useful? Regarding the...

@kedano, thanks. I did read through that earlier, but I prefer not splitting the document into `links` and `attributes`. Although I do admit there are certain advantages by doing that.

https://github.com/okb/Pomona/wiki/New-JSON-format

@asbjornu, I still think it looks really ugly, to embed the full media type in the document. In this context we already know that we're parsing JSON, and repeating that...

Also the `$type` should ideally resolve to an URI with metadata. I have not figured out exactly how we should do this yet, but it's important for supporting references across...

Btw, keeping the media type limited to describing the "outer" format is in no way against any REST principles or standards. It is perfectly viable, and seems to be the...

@asbjornu I got one more point to make here. I think the `$type` should be the same regardless of representation. The media type specifies the representation, but that could vary...

@GeirGrusom it's true that deserializing large JSON documents can be memory consuming when `$type` is not the first property provided. OData solves this by appending a `odata.streaming=true` parameter to the...