feat: support different body schema per content type by nflaig · Pull Request #5545 · fastify/fastify

nflaig · 2024-07-01T13:29:17Z

This allows to define a different body schema per content type. The same already exists for responses #4264 and should make fastify feature complete with openapi body definitions. See related issue for details about current limitations fastify/help#1012.

See test cases for examples or real world example.

This change is fully backward compatible.

Checklist

run npm run test and npm run benchmark
tests and/or benchmarks are included
documentation is changed or added
commit message and code follows the Developer's Certification of Origin
and the Code of conduct

mcollina · 2024-07-01T13:55:28Z

Great work, can you add docs and types?

ivan-tymoshenko

lgtm

ivan-tymoshenko · 2024-07-01T14:06:41Z

test/schema-validation.test.js

+      body: {
+        content: {
+          'application/json': {
+            schema: schemaArtist


Why this schema property is needed. Are you going to add some other properties to the mediatype object?

If we wanna solely support schema here it is not needed but I added it for two reasons

to semantically match openapi definition and current response schema added in feat: Supporting different content-type responses #4264

and to be able to add other properties such as description or example, although fastify itself doesn't care, upstream tooling like fastify-swagger can utitlize it

nflaig · 2024-07-01T15:20:03Z

Great work, can you add docs and types?

Not sure about types, the schema type itself is just unknown and there is no interface change

fastify/types/schema.d.ts

Line 11 in f8dbeaa

body?: unknown;

or maybe these? it's type any though, so technically valid

fastify/types/request.d.ts

Lines 92 to 93 in f8dbeaa

    
           getValidationFunction(schema: { [key: string]: any }): ValidationFunction 
        
           compileValidationSchema(schema: { [key: string]: any }, httpPart?: HTTPRequestPart): ValidationFunction

mcollina · 2024-07-02T11:55:54Z

linting is still failing

nflaig · 2024-07-02T12:23:27Z

linting is still failing

I've noticed that yesterday but I don't see how it is related to my changes, and somehow running npm run lint or --fix doesn't resolve the issue.

Seems like the extra semicolon was introduced here https://github.com/fastify/fastify/pull/5427/files#diff-5b6f7151989876bad33ac7d1a9ab6f8773d52bb1e37317a73ede4b2c45d7ca9cR69

Have removed it now for sake of making CI pass

mcollina

lgtm

lib/validation.js

metcoder95 · 2024-07-03T07:45:43Z

test/internals/validation.test.js

Can add some testing for encapsulated context and plugins?

Doesn't this cover the encapsulated context case? https://github.com/nflaig/fastify/blob/schema-per-content-type/test/internals/validation.test.js#L82-L106

On the plugin front do you mean adding test cases to test/schema-special-usage.test.js?

metcoder95 · 2024-07-03T07:46:03Z

test/schema-validation.test.js

Same as per my previous comment

docs/Reference/Validation-and-Serialization.md

Co-authored-by: Frazer Smith <frazer.dev@icloud.com> Signed-off-by: Nico Flaig <nflaig@protonmail.com>

gurgunday

I like the idea! A couple of thoughts:

We might sometimes need different schemas for querystring/params/headers too. So schema.body.content feels a bit limiting to me.

What if we had a schema.contentType property instead that could set schemas for all of them based on the content type:

{
  schema: {
    contentType: {
      'application/json': {
        body: {},
        querystring: {}
      }
    }
  }
}

Personally, it also felt a bit weird that schema.body would now have this special content property that would change its signature when it's present. Normally we'd just expect a JSON schema right under schema.body.

Maybe there's a better way to structure this API? Open to hearing others.

nflaig · 2024-07-03T12:34:44Z

I like the idea! A couple of thoughts:

I guess the current design is closely related to how the openapi definition works, so the assumption I made is that other params are the same, no matter what content type is sent in the request body. Which is limiting if you need that for sure, but if other params change as well, seems like a design issue of the route and might be better to add a separate route anyways.
If we think it's important to support (1) then to me this looks like a good pattern to use
This already exists for response schemas added in feat: Supporting different content-type responses #4264, if we don't want to add a special property to schema.body like content or as suggested in (2) then it would have to be a separate top-level field which seems strange to me as well. Semantically the content property is good imo because it closely matches the openapi definition.

climba03003 · 2024-07-03T18:09:38Z

Partially related to the PR, but I think we should reduce the syntax we accept for both body and response.
We are currently accepting

Shortened Schema (without type and properties)
Full Schema
Content Type with Shortened Schema
Content Type with Full Schema

The shortened schema is helpful when we support small set of feature.
But makes the code more complicate and too much branching right now.
Someone may accidentally mixed with Content Type with both Shortened and Full Schema without notice.

At least we should remove the choice for 3. and discuss if we should keep 1.

metcoder95 · 2024-07-04T07:41:22Z

Partially related to the PR, but I think we should reduce the syntax we accept for both body and response. We are currently accepting

Shortened Schema (without type and properties)

Full Schema

Content Type with Shortened Schema

Content Type with Full Schema

The shortened schema is helpful when we support small set of feature. But makes the code more complicate and too much branching right now. Someone may accidentally mixed with Content Type with both Shortened and Full Schema without notice.

At least we should remove the choice for 3. and discuss if we should keep 1.

I agree with @climba03003, the fact that we accept different kind of syntax makes slightly complicated to standardadize interesting tooling around the schemas on the implementers side.
I might suggest that it will be good to just accept an JSON schema one, unless of course the implementer has submitted a custom SchemaController.

gurgunday

lgtm

climba03003

I will start working on #5550 after this merge.

Eomm

LGTM - added few minor suggestion

lib/validation.js

lib/schemas.js

Co-authored-by: Manuel Spigolon <behemoth89@gmail.com> Signed-off-by: Nico Flaig <nflaig@protonmail.com>

mcollina

lgtm

* feat: support different body schema per content type * Add test for internal schema compiler * Consistent formatting of tests * Add test to avoid regression if types get stricter * Fix types test * Lint * Prefer single quoutes * Add docs with example schema * Remove unrelated formatting changes * Remove extra semicolon * Avoid using contractions Co-authored-by: Frazer Smith <frazer.dev@icloud.com> Signed-off-by: Nico Flaig <nflaig@protonmail.com> * Reduce branches Co-authored-by: Manuel Spigolon <behemoth89@gmail.com> Signed-off-by: Nico Flaig <nflaig@protonmail.com> * Consistent variable naming * Add todo for adding request.contentType * Reduce nesting --------- Signed-off-by: Nico Flaig <nflaig@protonmail.com> Co-authored-by: Frazer Smith <frazer.dev@icloud.com> Co-authored-by: Manuel Spigolon <behemoth89@gmail.com> (cherry picked from commit f3ee7f7)

* feat: support different body schema per content type * Add test for internal schema compiler * Consistent formatting of tests * Add test to avoid regression if types get stricter * Fix types test * Lint * Prefer single quoutes * Add docs with example schema * Remove unrelated formatting changes * Remove extra semicolon * Avoid using contractions Co-authored-by: Frazer Smith <frazer.dev@icloud.com> Signed-off-by: Nico Flaig <nflaig@protonmail.com> * Reduce branches Co-authored-by: Manuel Spigolon <behemoth89@gmail.com> Signed-off-by: Nico Flaig <nflaig@protonmail.com> * Consistent variable naming * Add todo for adding request.contentType * Reduce nesting --------- Signed-off-by: Nico Flaig <nflaig@protonmail.com> Co-authored-by: Frazer Smith <frazer.dev@icloud.com> Co-authored-by: Manuel Spigolon <behemoth89@gmail.com> (cherry picked from commit f3ee7f7) Co-authored-by: Nico Flaig <nflaig@protonmail.com>

erunion · 2024-08-15T21:51:45Z

👋 When and where should we expect this to land? Seems it didn't make the v4.28.1 release in late July.

github-actions · 2025-08-16T00:31:39Z

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

feat: support different body schema per content type

cd1055c

This was referenced Jul 1, 2024

JSON schema validation is called for application/octet-stream fastify/help#1012

Closed

chore: clean up workaround in ssz content type parser ChainSafe/lodestar#6926

Closed

mcollina requested review from Eomm and ivan-tymoshenko July 1, 2024 13:53

mcollina added the backport 4.x Issue or pr that should be backported to Fastify v4 label Jul 1, 2024

Eomm self-assigned this Jul 1, 2024

ivan-tymoshenko approved these changes Jul 1, 2024

View reviewed changes

Add test for internal schema compiler

b12b161

nflaig added 3 commits July 1, 2024 16:25

Consistent formatting of tests

dbf40c0

Merge branch 'main' into schema-per-content-type

fe7fe82

Add test to avoid regression if types get stricter

9a3b52f

github-actions bot added the typescript TypeScript related label Jul 1, 2024

nflaig added 4 commits July 1, 2024 18:13

Fix types test

0473376

Lint

da35ff4

Prefer single quoutes

d13ecac

Add docs with example schema

a538a8e

github-actions bot added the documentation Improvements or additions to documentation label Jul 1, 2024

Remove unrelated formatting changes

176d879

Remove extra semicolon

6cdbed2

mcollina approved these changes Jul 2, 2024

View reviewed changes

metcoder95 reviewed Jul 3, 2024

View reviewed changes

Fdawgs reviewed Jul 3, 2024

View reviewed changes

docs/Reference/Validation-and-Serialization.md Outdated Show resolved Hide resolved

Avoid using contractions

9cc9fa4

Co-authored-by: Frazer Smith <frazer.dev@icloud.com> Signed-off-by: Nico Flaig <nflaig@protonmail.com>

gurgunday requested changes Jul 3, 2024

View reviewed changes

climba03003 mentioned this pull request Jul 4, 2024

Review on supporting schema shortened #5550

Closed

2 tasks

gurgunday approved these changes Jul 4, 2024

View reviewed changes

climba03003 approved these changes Jul 6, 2024

View reviewed changes

Eomm reviewed Jul 7, 2024

View reviewed changes

lib/validation.js Outdated Show resolved Hide resolved

lib/validation.js Outdated Show resolved Hide resolved

lib/schemas.js Outdated Show resolved Hide resolved

nflaig and others added 5 commits July 7, 2024 14:45

Reduce branches

d9c57df

Co-authored-by: Manuel Spigolon <behemoth89@gmail.com> Signed-off-by: Nico Flaig <nflaig@protonmail.com>

Consistent variable naming

c320934

Add todo for adding request.contentType

4d966ee

Reduce nesting

2d6ffc2

Merge branch 'main' into schema-per-content-type

01b53f4

mcollina approved these changes Jul 9, 2024

View reviewed changes

mcollina merged commit f3ee7f7 into fastify:main Jul 9, 2024

github-actions bot mentioned this pull request Jul 9, 2024

[Backport 4.x] feat: support different body schema per content type #5559

Merged

vivedo mentioned this pull request Sep 17, 2024

feat: support multiple content type schemas per request body fastify/fastify-swagger#819

Merged

3 tasks

nflaig mentioned this pull request Sep 23, 2024

chore: upgrade fastify to v5 ChainSafe/lodestar#7101

Merged

lholmquist mentioned this pull request Oct 31, 2024

[Snyk] Upgrade fastify from 4.21.0 to 5.0.0 nodeshift/faas-js-runtime#370

Closed

p-bakker mentioned this pull request Mar 26, 2025

Support multiple ContentTypes per route seriousme/fastify-openapi-glue#648

Closed

github-actions bot locked as resolved and limited conversation to collaborators Aug 16, 2025

Uh oh!

Conversation

nflaig commented Jul 1, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Checklist

Uh oh!

mcollina commented Jul 1, 2024

Uh oh!

ivan-tymoshenko left a comment

Choose a reason for hiding this comment

Uh oh!

ivan-tymoshenko Jul 1, 2024

Choose a reason for hiding this comment

Uh oh!

nflaig Jul 1, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nflaig commented Jul 1, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mcollina commented Jul 2, 2024

Uh oh!

nflaig commented Jul 2, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mcollina left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

metcoder95 Jul 3, 2024

Choose a reason for hiding this comment

Uh oh!

nflaig Jul 3, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

metcoder95 Jul 3, 2024

Choose a reason for hiding this comment

Uh oh!

Uh oh!

gurgunday left a comment

Choose a reason for hiding this comment

Uh oh!

nflaig commented Jul 3, 2024

Uh oh!

climba03003 commented Jul 3, 2024

Uh oh!

metcoder95 commented Jul 4, 2024

Uh oh!

gurgunday left a comment

Choose a reason for hiding this comment

Uh oh!

climba03003 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Eomm left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mcollina left a comment

Choose a reason for hiding this comment

Uh oh!

erunion commented Aug 15, 2024

Uh oh!

github-actions bot commented Aug 16, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

nflaig commented Jul 1, 2024 •

edited

Loading

nflaig Jul 1, 2024 •

edited

Loading

nflaig commented Jul 1, 2024 •

edited

Loading

nflaig commented Jul 2, 2024 •

edited

Loading

nflaig Jul 3, 2024 •

edited

Loading

climba03003 left a comment •

edited

Loading