Transit is not the default format in the Accept header

[amacdougall]

The README says that the default request and response format is Transit, presumably "application/transit+json". However, when I send a request with no format or content-type information, the "Accept" header has "application/json" before "application/transit+json". The README says that the response format is derived from the "Content-Type" header, but specifying a content type for the request did not make a difference.

(GET "/api/users"
  {:handler ...})

The "Accept" header in the request is "Accept:application/json; charset=utf-8, application/transit+json; charset=utf-8, application/transit+transit; charset=utf-8, text/plain; charset=utf-8, text/html; charset=utf-8, /; charset=utf-8". At least according to the Chrome devtools network tab!

(GET "/api/users"
  {:headers {"Content-Type" "application/transit+json"}
   :handler ...})

Although the "Content-Type" header was present in the request, the "Accepts" header did not change.

(GET "/api/users"
  {:response-format :transit
   :handler ...})

This version produced this "Accept" header: "Accept:application/transit+json; charset=utf-8".

I'm totally fine with just specifying a response format, but this behavior does seem to deviate from the documentation.

If this is actually an issue, fixing it may be as simple as reordering ajax.core/default-formats to put "application/transit+json" first.

[JulianBirch]

I think it would probably be worth doing that re-ordering, since it'll help things like yada and liberator make the correct decision. Want to send a PR?

[amacdougall]

Sure thing. I'll brew one up when I get a chance.

[camdez]

I've been digging on this a little...think I can shed light on a few things.

1. RE the docs saying the default request and response format is Transit, I definitely agree that this is in error. The default Accept is the set of all formats the library supports, with a preference for JSON. This should change since Transit is more expressive; no sense in downgrading the fidelity of data if something richer is available.
2. What it will do by default, and likely what the docs were aiming for, is encode the request as Transmit (this means setting the Content-Type and formatting the request body). Note that this does not affect GET requests—they have no body and no content type, regardless of whether or not the user specified a :format, so your test case above would not reveal any change in behavior.
3. RE "The README says that the response format is derived from the "Content-Type" header, but specifying a content type for the request did not make a difference.", I believe the docs are referring to the Content-Type of the response; if the :response-format is not provided, the library will decide how to parse the data based on the Content-Type header of the response. If the :response-format is specified, the library will insist on parsing the response in the expected format, regardless of what the server actually says the content is.
4. In addition to influencing how the request body will be parsed, the :response-format key also affects the Accept header that is sent with the request—if we say we're expecting (e.g.) JSON, we send a JSON Accept header, and treat whatever we get back as JSON, regardless of what the server actually tells us.

I'll whip up a pull request to change the format order and see if I can improve the docs a little.