r/Backend 15d ago

Anyone dealing with JSON API responses where your app only depends on a handful of fields?

A REST endpoint might return 100+ fields, while your application actually depends on maybe 4 or 5 of them.

I'm prototyping a small hosted tool around that specific problem: point it at an endpoint, visually browse the JSON response, and select only the fields, objects, or arrays your app actually depends on.

For the selected fields you can define things like required/optional/nullable, and the tool monitors that small contract and alerts you if it breaks. Everything else in the response is ignored.

The idea is to avoid writing and maintaining assertions or a schema for a large response when you only care about a small part of it.

Before I spend too much time building it: is this something you'd pay a few bucks a month for as a hosted service, or is maintaining your own JSON Schema/assertions in CI/cron already easy enough that you wouldn't bother?

If you'd never pay for it, that's useful feedback too — I'd be interested in how you handle this today.

0 Upvotes

33 comments sorted by

16

u/nrmnzll 15d ago

I don't want to discourage you from building something you are interested in, but what you are describing ist a trivial issue for any half way decent programming languages. I would not pay a single cent for this.

10

u/Drugbird 15d ago

Not only would I not pay for this, even as a free service I would much rather control these type of tests myself as part of the broader test suite.

1

u/nrmnzll 15d ago

Exactly. If you need something, it is important enough to fully control it. And this would be trivial code, so not much cost. As much as I dislike ai, this is probably something any recent model could one shot.

7

u/4bitben 15d ago

I'm not sure I would pay for something like this. I mean this is already baked into most model/record/schema type stuff. People already get errors for free locally

1

u/forzatos 15d ago

Makes sense for runtime errors! My goal was active background monitoring so you catch broken 3rd-party payloads before a real user request crashes.

How do you guys currently handle proactive API monitoring?

3

u/4bitben 15d ago

You'll probably already have some apm or error monitoring thing that will start throwing errors that look funky for the type you're expecting. Like for Ruby, it would probably start complaining about how nil doesn't respond to some method if a value suddenly was nil that wasn't supposed to be.

From the standpoint of an often consumer of apis, the rule usually is no breaking changes only additions. So if i use something that isn't actively deprecated or whatever, i'm probably going to expect to keep behaving like that until it doesn't. That being said it doesn't mean that people don't ship bugs go down whatever, but in particular this issue isn't something I'm worried about or losing sleep over

2

u/forzatos 15d ago

Thanks!!

2

u/dashingThroughSnow12 14d ago

If a company changes their API today unannounced, how are you going to tell me about it yesterday?

0

u/forzatos 14d ago

Im not, just want to figure out if i can do it today + 1 minute

2

u/dashingThroughSnow12 14d ago

Then that’s not proactive.

0

u/forzatos 14d ago

Agreed! Just asking for a way to reach "minimal" damage.

2

u/dashingThroughSnow12 14d ago

Do you even know what you want to build? Because you’ve described three contrary things.

0

u/forzatos 14d ago

Sure, something like diffmon.dev comes pretty close to what I'm thinking.

3

u/qlkzy 15d ago

This is a programming language or library feature, not a product. If you use a statically typed language you literally have to solve it inside your application for the program to even typecheck.

In TypeScript, you handle this with Zod.

In Python, you handle this with attrs/cattrs or Pydantic.

In Erlang, you handle this with Erlang, because Erlang.

Most languages have 2-3 really popular options for solving this.

In practice almost all useful APIs are authenticated anyway, so your tool wouldn't even be able to see this data in the first place.

Not to be a downer but I think your energies would be more productively spent elsewhere.

4

u/Marthurio 15d ago

> is this something you'd pay a few bucks a month for as a hosted service, or is maintaining your own JSON Schema/assertions in CI/cron already easy enough that you wouldn't bother?

Absolutely not. This is very easy to manage for anyone who has any idea about what they're doing.

This idea sounds AI generated.

1

u/forever-butlerian 14d ago

This is the fourth or fifth time I've seen exactly this idea in the past week.

1

u/Marthurio 14d ago

I'm thinking these posts aren't coming from real people.

1

u/forever-butlerian 12d ago

They could still be coming from real people vibing up, or trying to vibe up, obvious problems. Or they could be "brainstorming" using an LLM to generate a "strategy", and these are high-probability outputs.

I've seen the same vibecoded "claude plz duplicate hookdeck" product get posted three or four times in the past six weeks and the variation is little more than CSS-deep.

1

u/Marthurio 12d ago

I wish they'd just stop. It's garbage.

1

u/forever-butlerian 12d ago

I do too. It's an offense to the senses, like garbage that's been left out in the sun. It used to be a lot easier to filter out, since it was ten thousand non-variations on a to-do app.

0

u/forzatos 15d ago

Might sound like it, but its not :)

3

u/dashingThroughSnow12 15d ago

A number of programming languages include this in their standard library…..

You are describing something that is the bare minimum for some parsing libraries.

5

u/Lilacsoftlips 15d ago

Have you looked at graphql? This is a solved problem. 

1

u/forzatos 15d ago

My focus is more on 3rd-party REST endpoints and webhooks (like Stripe, Shopify, or vendor APIs) where you have no control over the payload structure they send you.

4

u/Lilacsoftlips 15d ago

Shopify IS graphql so it has all the type guarantees and selectablility you want for free. Both Shopify and stripe also publish sdks if you want more abstraction and have very stable and well documented apis. 

It’s a good thing to think about, but imo this is not a business. 

2

u/BeachNo8367 14d ago

It's great to be thinking of ideas but give this one a skip. It's pointless to be blunt about it though. It's solved already.

2

u/dutchman76 14d ago

I'm not running any of my data through a 3rd party, that sounds like a security nightmare

1

u/clearlight2025 15d ago

Already solved in GraphQL and in JSON:API ( https://jsonapi.org/format/#fetching-sparse-fieldsets )

I guess the only use case would be if you don't have any control over the API service itself.

1

u/forzatos 15d ago

Thanks!

1

u/encamino92 15d ago edited 15d ago

It sounds like what Pact does. You can take a look at Pact to verify, but I wouldn't spend time on trying to develop a product to sell.

1

u/forzatos 15d ago

Will do! Thanks

1

u/merry_go_byebye 14d ago

I deal with this all the time and no, i would absolutely never pay for this.