Asbjørn Ulsberg

Reopening this. We can instead discuss whether it should be in the backlog or a part of 2.0. I'd prefer it to be in 2.0 since this will be a...

What we need to look at is [OData 4.0 Query Options](http://docs.oasis-open.org/odata/odata/v4.0/errata02/os/complete/part2-url-conventions/odata-v4.0-errata02-os-part2-url-conventions-complete.html#_Toc406398092).

Now there's [LinqToQuerystring](https://github.com/beyond-code-github/LinqToQuerystring) that hopefully can work as a drop-in implementation of OData 4.0 Query Options.

Now we have [JavaScript Object Notation (JSON) Text Sequences (RFC 7464)](https://tools.ietf.org/html/rfc7464) as a standardized way to encode endless streams of data as well. With that, we have something that will...

Haha indeed! :smile:

As recommended in [The RESTful Cookbok](http://restcookbook.com/Resources/using-custom-content-types/), I think we should define something like `application/vnd.service.entity+json; version=X`. This is both human readable, generic (`json`), specifies the service (`service`), the entity type (`entity`)...

I'm thinking that whenever `type` is necessary, it should be the HTTP `Content-Type` and not the internal, C# specific `System.Type`. There should be a convention-based mapping between the two, but...

I'm not argumenting for the removal of `type` from the HTTP body. I'm just argumenting for using a full MIME Media Type wherever `type` in any form is necessary, be...

I agree, @GeirGrusom. @BeeWarloc wrote: > I find using the full media type inside the document awkward and too verbose. > Could you describe a specific real life scenario where...

I completely agree that everything related to "Multipurpose Internet Mail Extensions" is ugly, but that's the standard we have, unfortunately. Having different "type" concepts in the API is a bad...