Content-Negotiation with Accept: text/html & Accept: application/json

[kael]

I'm trying to use Remix for dual content-negotiation with HTML and JSON.

With Remix, it's possible to handle content-negotiation in the loader by checking the content-type, using the resource routes pattern, (without default exported component).

But I can't seem to find a way to use Remix for content-negotiation for text/html and application/json.

Can Remix handle this case of content-negotiation ?

curl -LH "Accept: text/html" http://127.0.0.1:8788/

curl -LH "Accept: application/json" http://127.0.0.1:8788/

[machour]

This is not supported for now.
We do have a proposal to support the Accept header: #5024

[kael]

I seem to have find a way to do dual content-negotiation by using a redirect in the loader depending on the Accept header, with a second module structured as a "resource route" one:

• Main module (HTML): /routes/user/$id.js:

import { json, redirect } from "@remix-run/cloudflare";
import { useLoaderData, } from "@remix-run/react";

import * as Users from '~/data/users';

export const loader = async ({ request, params: { id } }) => {
  // Check `Accept` header and redirect to JSON loader handler if it's `application/json`
  if (request.headers.get('accept') === 'application/json') return redirect(request.url + '.json');
  const user = Users[id];
  if (user) return { user };
  throw json("User Not Found", { status: 404 })
};

export default function Report(request ) {
  const { user: { name, familyName } } = useLoaderData();
  return (
    <div>
      <p>Name: {name}</p>
      <p>Family Name: {familyName}</p>
    </div>
  );
}

• Alternate module (JSON): /routes/user/$id[.json].js

import { json, redirect } from "@remix-run/cloudflare";
import * as Users from '~/data/users';

export const loader = async ({ request, params: { id } }) => {
  const user = Users[id];
  if (user)  return json({ user }, { headers: { 'content-type': 'application/json' } });
  return json('User not found', { status: 404 });
};

It is a proper way to do, or is there some anti-pattern somewhere ?

[sergiodxa]

I think the only issue with that could be if the client fetching your loader doesn't follow redirects, for example I never expect APIs send a redirect response so I usually do:

let response = await fetch(url, {
  redirect: "error"
})

That way if the API returns a redirect the fetch will throw.

[kael]

That way if the API returns a redirect the fetch will throw.

Interesting remark. I actually use redirect: "follow" with APIs as I trust they know where they redirect.

It's possible to do content-negotiation with DOI URLs, and their server returns a 302 redirect to the API URL, though:

$ curl --head -LH "Accept: application/vnd.schemaorg.ld+json" https://doi.org/10.5438/4K3M-NYVG
HTTP/2 302 
date: Thu, 16 Feb 2023 18:07:26 GMT
content-type: text/html;charset=utf-8
content-length: 177
location: https://data.crosscite.org/10.5438%2F4K3M-NYVG
vary: Accept
expires: Thu, 16 Feb 2023 18:50:05 GMT
...

HTTP/2 200 
date: Thu, 16 Feb 2023 18:07:26 GMT
content-type: application/vnd.schemaorg.ld+json; charset=utf-8
status: 200 OK
cache-control: max-age=0, private, must-revalidate
vary: Accept-Encoding, Origin
etag: W/"7ee8ff95bb14983bee5190484aa61c6f"
x-runtime: 0.012087
x-request-id: 0c4578fe-95c9-402d-8857-5bf840bd24ea
x-powered-by: Phusion Passenger(R) 6.0.13
server: nginx/1.18.0 + Phusion Passenger(R) 6.0.13

The above combination of components modules for dual content-negotiation looks good.

It'd be great if Remix could handle the Accept header with the ;q= quality values out-of-the box. In the meantime, this solution looks fine to me.

There's a mention of a "hack" using some internal _data URLSearchParams that can be used for content-negotiation, would there be an example of use of the _data param ? I skimmed the code but didn't find from where to get the routeId.

---

Addendum: DOI Content Negotiation