_e.g._ `?input=${JSON.stringify(encodeURIComponent(input))` |\r\n| `POST` | `.mutation()` | Input as post body. | \r\n\r\n## Considerations with OpenAPI\r\n\r\n- Resources are usually `/{resource}/{id}?param1=x¶m2=y`-style - tRPC is [currently] with `{resource}?input=JSON.stringify(encodeURIComponent(input))`-style\r\n- JSON-RPC based response shape might not be the ideal response shape for OpenAPI\r\n- An output schema usually have a `$ref`-schema which would be possible to do automatically / first feature people would request is to make different paths request the same input type\r\n- Actually using zod or any other validation on a resolver's `output` would slow down API outputs.\r\n\r\n## Related\r\n\r\nhttps://github.com/trpc/trpc/discussions/271\r\n",[2920,2923],{"name":2921,"color":2922},"🙋♂️ help wanted","008672",{"name":2924,"color":2925},"💬 discussion","4B318A",755,"[RFC] Using tRPC for public-facing APIs (OpenAPI/Swagger/etc)","2022-06-19T00:48:45Z","https://github.com/trpc/trpc/issues/755",0.69406897,{"description":2932,"labels":2933,"number":2937,"owner":2868,"repository":2868,"state":2904,"title":2938,"updated_at":2939,"url":2940,"score":2941},"Would be possible for each query/mut to have a `schema:`-prop next to the resolver where one could define an api schema of which the structure could be statically enforced as well.\n\nMaybe the input arg of the schema could also be used as an actual input validator?\n\n\n---\n\nAnother way could possibly be to statically infer the swagger schema with codegen, but then one couldn't actually _document_ properties. ",[2934],{"name":2935,"color":2936},"@trpc/server","9BE78E",164,"[RFC] OpenAPI aka swagger support ","2021-04-12T21:58:25Z","https://github.com/trpc/trpc/issues/164",0.69419885,{"description":2943,"labels":2944,"number":2945,"owner":2868,"repository":2868,"state":2904,"title":2946,"updated_at":2947,"url":2948,"score":2949},"https://github.com/trpc/trpc/blob/d5808b863490f95ff76defce4886833b11672e88/packages/server/src/adapters/fastify/fastifyTRPCPlugin.ts#L25-L31\r\n\r\nThis works just fine for tRPC endpoints but breaks other REST api endpoints as `request.body` is a string where it's expected to an object. This can be easily reproduced on the official fastify examples by creating a REST `POST` endpoint and sending some data inside body.",[],1715,"Fastify adapter: Custom content-type parser for application/json is breaking normal REST api requests on a fastify server","2022-10-04T12:03:17Z","https://github.com/trpc/trpc/issues/1715",0.70328534,{"description":2951,"labels":2952,"number":2959,"owner":2868,"repository":2868,"state":2904,"title":2960,"updated_at":2961,"url":2962,"score":2963},"This is a proposal for a new content type API that will augment or replace the current [`transformer` API](https://trpc.io/docs/data-transformers).\r\n\r\nDraft implementation in #2351\r\ndiscussion in #1937\r\n### Why? Is it necessary to support more than just JSON?\r\nI'll argue in favor of this. Supporting more content types allows us to shrink the size of the query URLs with smaller inputs and the size of the responses from the API. Most users also use [Superjson](https://github.com/blitz-js/superjson) to support a wider range of data types. However, Superjson is very inefficient at this (see https://github.com/blitz-js/superjson/issues/38) and JSON may not be the best format. Other formats like https://github.com/pieroxy/lz-string compress data to be much smaller.\r\n\r\nAnother important goal of this API is to enable streaming files from the client. We only support JSON currently so the current solution is for the client to request a pre-signed storage URL (for something like S3) and stream the file to that URL or encode the file to base64 and send that string in the JSON body, which is slow and inefficient. Having the ability to define a procedure that accepts a file stream has the potential to greatly simplify this flow.\r\n\r\n> Why use tRPC vs. a normal API route then?\r\n\r\nIf you define it within the tRPC router, you can keep the same context and middleware flow instead of having to redefine that as an API route. You can also, of course, upload files to your API route in a typesafe manner.\r\n\r\n### Server\r\nThe goals of content types on the server are enabling streaming requests and responses, supporting additional JS data types, and faster serialization. \r\nThe entry point for most users can look something like this, similar to how you would define a transformer:\r\n```ts\r\nconst t = initTRPC()({\r\n contentTypes: [superjsonContentType]\r\n})\r\n\r\n// per procedure?\r\nt.procedure.contentTypes([superjsonContentType]).query(() => {\r\n return {\r\n createdAt: new Date()\r\n }\r\n})\r\n```\r\nWe also must provide some way of specifying content types per procedure. For example, you might want one specific procedure to only accept the multipart data content type. This makes batching requests very difficult. One way it could work is the content types would indicate if they support batching. Then on the client, requests in a batch would be grouped based on their content types and individual requests would be fired for each content type group. This is a very complex solution and I'm not sure we want to go down that route, but I also can't think of an alternative.\r\n\r\nHere, `superjsonContentType` will be an object with methods for deserializing and serializing in different situations. The same object will be passed to `initTRPC` on the server and also imported on the client. For the server's needs, the content type should have methods to do the following:\r\n- for queries, accept input via a URL parameter and be able to deserialize it \r\n- for mutations, accept a stream or string from the client and be able to deserialize it\r\n - passing a stream to the content type is considerably difficult because we're agnostic to the server framework. Ideally, we'd coerce everything to the Fetch API (related: #1853)\r\n- for responses, they should be streamable or just strings\r\n\r\n> **Note**\r\n> I am purposefully not outlining what an API for defining content types could look like. Instead, I am only going to define our goals/requirements for them.\r\n\r\n### Client\r\nOn the client side, content types will unlock the usage of all contents with tRPC, not just JSON-based ones. The API could look like the following:\r\n```ts\r\nconst client = createTRPCClient({\r\n // this would be used for all requests if there isn't an override specified\r\n defaultContentType: superjsonContentType\r\n})\r\n\r\nconst proxy = createTRPCClientProxy(client)\r\n\r\n// specify/override per query\r\nconst user = proxy.uploadFile(/* multipart data stream */, {\r\n contentType: multipartContentType\r\n})\r\n```\r\n\r\nAs I said above, we must consider the batching implications. Different content types must be different requests, but batching is still essential for us to support.\r\n\r\nFor the client, the content type should be able to do the following:\r\n- for mutations, be able to stream input\r\n- for receiving streamed responses, be able to deserialize output as it's being read from the stream\r\n\r\n\r\n### JSON Interfaces\r\nI \\*really do not\\* want a `transformer` and content type API. tRPC's config is already complex as is. If anything at this point, we should be seeking to simplify it.\r\n\r\nHowever, there are special considerations for things that will serialize to JSON anyway. An example is the SSR/[SSG flow with Next.js](https://alpha.trpc.io/docs/ssg-helpers#nextjs-example). We send a prop to the page from the server called `trpcState` which is serialized to JSON by Next.js. In this case, we will incur the cost of serialization twice, once when serializing the data with the content type and again when Next.js serializes the serialized data to JSON. I'm not sure what solutions we can offer for this. We may be forced to keep the `transformer` prop around or accept a special method on each content type to handle coercion to a JSON-serializable object.\r\n\r\n### Additional Considerations\r\nThis RFC is purposefully vague on implementation details. I'd rather we first discuss the goals and then build an API based on those.\r\n\r\nI believe this proposal would introduce more complexity into the codebase, especially considering interop with `transformer`. Interop is definitely possible but it makes the implementation more difficult. This also may take a bit of time, an important consideration when we also have the new proxy API to focus on. It could be in our best interest right now to ignore this and address it after v10.\r\n\r\n---\r\n\r\nIf there's anything that isn't clear or I missed something that I should have addressed, please leave a comment. ",[2953,2956],{"name":2954,"color":2955},"next-major/maybe","D4C5F9",{"name":2957,"color":2958},"RFC","78B062",2387,"RFC: Content Types","2022-08-09T18:11:32Z","https://github.com/trpc/trpc/issues/2387",0.70556015,{"description":2965,"labels":2966,"number":2971,"owner":2868,"repository":2868,"state":2904,"title":2972,"updated_at":2973,"url":2974,"score":2975},"### Provide environment information\r\n\r\n10.23.0\r\n\r\n### Describe the bug\r\n\r\n- Posting JSON as body without setting `content-type: application/json` will be an error.\r\n- This was not the behavior prior to #4256\r\n- Only applies to when the API handler has preprocessed the request (e.g. Next.js automatically supplying a `req.body`)\r\n\r\n### Link to reproduction\r\n\r\ntodo\r\n\r\n### To reproduce\r\n\r\nPost JSON body w/o `content-type: application/json` to a mutation in a Next.js API handler.\r\n\r\n### Additional information\r\n\r\n_No response_\r\n\r\n### 👨👧👦 Contributing\r\n\r\n- [X] 🙋♂️ Yes, I'd be down to file a PR fixing this bug!",[2967,2970],{"name":2968,"color":2969},"🐛 bug","d73a4a",{"name":2935,"color":2936},4292,"bug: trpc doesn't assume `content-type` json anymore","2023-05-17T12:02:10Z","https://github.com/trpc/trpc/issues/4292",0.7096587,["Reactive",2977],{},["Set"],["ShallowReactive",2980],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$flT6cy5PKPfEJQFbZcMm5H6BefoujDbDDGc72TFlHmC8":-1},"/trpc/trpc-openapi/187"]