Make fields mandatory ?

[nfaugout-lucca]

When you want to change your API surface (new field, rename field, change field type), it would be great if you could see who is effectively using your API, and which fields they are using.

This way, your can decide whether you can safely change the field (breaking change) or if you have to take uses of your field in account and be backward compatible for a while.

One way of ensuring this is to make the fields query parameter mandatory.

Users of your API should now explicitely tell which fields of your resources they are relying on.

Related to #53, #214

[Poltuu]

one way to fix this, is to change the default api/xxx to only exposing id,name,url.
But then you need a proper way to explore the objet, probably thanks to swagger

[rducom]

it would be great if you could see who is effectively using your API, and which fields they are using.

It's logging related : if you want to see effectively all the used fields, you have to iterate de logs

making the fields query parameter mandatory

If we do this, we loose the easy and sexy way of using our API : just write the resource route, then navigate with uri

[nfaugout-lucca]

one way to fix this, is to change the default api/xxx to only exposing id,name,url.

In my case, that was a query on the collection. And here I assume that we won't restrict collection calls to only id,name,url in returned JSON.

It's logging related

Not sure to understand ? Logs does not contains response bodies, and you don't know what the caller will do with the returned JSON.

If we do this, we loose the easy and sexy way of using our API : just write the resource route, then navigate with uri

One point ;)

We could make fields mandatory IF you want to get other fields than id,name,url.

And if you do not precise fields, you only get id,name,url, no matter it's a collection or entity call.

Good for you ?

[Poltuu]

You have to assume that the caller knows what he's doing of course, and will consume exactmy what he asked.

Before changing anything and agreeing on a solution, i'd like to assess if that's a real problem thus.

I agree with @rducom that logging seems to be the natural way to handle this