Proposal: Response.json helper

[lucacasonato]

The Response object currently has a Response.redirect helper method to create Response objects with preset Location headers. Request and Response already have a json prototype method that allows parsing bodies as JSON, but there is currently no trivial one-liner to create JSON Response objects directly from a POJO.

I propose the addition of a Response.json(obj, opts) static method that creates a Response object with a body string containing the JSON serialized representation of obj. opts would allow further modification of the JSON response, namely setting headers and status code. By default the status code is 200, and the headers are the default response headers + content-type: application/json.

interface Response {
  [NewObject] static Response json(any object, optional ResponseInit init = {});
}

The motivation for this addition is that in server side runtimes using WHATWG Request and Response objects, folks often create helper methods for this behaviour that need to be duplicated across each project. This being built in would be very useful.

Thoughts?

Implementer interest:

• Chromium ✔️
• Firefox ✔️
• Safari ❔
• Deno ✔️
• Cloudflare Workers ✔️

[jasnell]

Yeah, Workers would be interested in this!

[lucacasonato]

If Response.json does not work due to the conflict with the prototype json method, I'd also be happy with a Response.fromJSON.

[leerob]

Vercel would be interested in this!

[Jarred-Sumner]

Bun would be interested in this!

[fabiancook]

Following, to replace the code here

The current minimum:

    respondWith(
        new Response(JSON.stringify({
            data: "value!"
        }), {
            headers: {
                "Content-Type": "application/json"
            }
        })
    )

This would reduce the code to:

    respondWith(
        Response.json({
            data: "value!"
        })
    )

Looks great 👍🏻

[mjackson]

Remix already implements this and it’s super handy. 👍

[SukkaW]

Is it handy? Obviously yes. Is it good? Probably not.
If Response.json is added, sooner or later we will have to add Response.arrayBuffer, Response.blob, Response.text / Response.string (And maybe some people / companies even want Response.formData).

[fabiancook]

It would make sense to include all these others.

For Response.arrayBuffer we would use the default header Content-Type: application/octet-stream.

For Response.blob, grab from blob.type

For Response.text we could use text/plain by default, while still allowing Content-Type: text/html to be passed through init

And for Response.formData, Content-Type: multipart/form-data

[lucacasonato]

Is it handy? Obviously yes. Is it good? Probably not.
If Response.json is added, sooner or later we will have to add Response.arrayBuffer, Response.blob, Response.text / Response.string (And maybe some people / companies even want Response.formData).

@SukkaW No need to add those, as those already exist. They are overloads of the new Response constructor. Example:

const resp = new Response(new ArrayBuffer(5));
const resp = new Response(new Blob(["hello world"]));
const resp = new Response("foo bar");
const resp = new Response(new FormData());

The only reason JSON can't be included in the overload is that the plain object can not be differentiated from other object inputs in a non confusing manner.

[ricea]

JFYI, I requested a W3C TAG review of this feature in preparation for shipping in Chrome: w3ctag/design-reviews#741

[zcorpan]

I'll note that at least the Geometry API has static methods with fromX naming scheme, e.g.:

https://drafts.fxtf.org/geometry/#dommatrix

It seems easier to find the right documentation between Response.json and Response.prototype.json if they have different names.

Response.json(obj) is slightly easier to type than Response.fromJSON(obj), though personally I think the latter is more obvious what it does.

[silverwind]

I find the naming of this highly confusing. MDN for example lists Response.json which is actually Response.prototype.json and not this static method. Naming it Response.from or Response.fromJSON would be in line withArray.from. W3C has similar concerns.

[annevk]

That is being tracked by mdn/content#21550. I think this has shipped so I don't think we're in a position to rename.

I think the name is reasonable and consistent with other names on the object. That it pushes the ecosystem to no longer conflate statics and non-statics is a bonus.

[karlhorky]

I proposed that types for the Response.json() static method be added to TypeScript over here:

• Types for Response.json() Static Method microsoft/TypeScript#52841