2
When I made my first Rest API, I defined my JSON structure and always returned that same structure even if the pair had given it or not. I talked to a new co-worker and he presented me another perspective. If the pair has not given, it is issued to save traffic on the network. My question is this is good practice?
3
Forget this good practice business. It only uses this two kinds of programmers: the one who doesn’t understand what they’re doing and will use everything wrong, or the very experienced programmer and understands how good practice should be used, that it’s just a guide, often with bias, which does not take into account the context where it is being applied, and should only give an idea of what to observe, never blindly follow that.
In this case, there’s no way to know what to do because we don’t have the context. We do not know if it is a problem to omit (I imagine that it would not make sense to "send" as in the question) the key to the field that has no value. There are cases where the interpretation of not having the element may be different from it not having a value. It may give versioning problem, for example.
If you want to save traffic you can think of another format. You can use a format that doesn’t need to have the key repeatedly, just a header. This gives an absurdly greater gain. But it cannot be used in all cases. It can do some kind of compression, in some cases it can be useful, in others it can be innocuous and have other costs that does not compensate the use.
2
Well, as I understand it, you’re talking about omitting a null attribute. For example, instead of returning:
{
atributo1: "Hello",
atributo2: null,
}
Your colleague recommends:
{
atributo1: "Hello"
}
This is not recommended and I believe that data saving is insignificant in most cases.
Your API contract must return (sponse) always the same fields, as omitting one of them leads to breach of contract and can cause various problems understanding your API. Already in sending (request) you can be more flexible yes, but aiming for API flexibility (to evade a version of the API, for example) and not data saving.
Finally, according to the principle of robustness (or Postel’s Law) alert us:
Postel’s Law States that you should be liberal in what you Accept and Conservative in what you send.
Browser other questions tagged json rest restful
You are not signed in. Login or sign up in order to post.
What do you mean
par? Can you give an example? Well, as I understand it, this is not recommended and I believe that data saving is insignificant in most cases. Your API contract should always return (Answer) the same fields, as omitting one of them leads to breach of contract and can cause various problems understanding your API. On the request you can be more flexible yes, but aiming at API flexibility and not data saving.– Dherik
As good REST practices you should always use the requisition protocols. In this case that there is no data you must return the status code 204 which means Nocontent(without content). This way you respect the request protocols and save data traffic on the network.
– Maycon F. Castro
@Dherik when I say "pair" I mean the attribute and its value. Example: {"code":245}. But I understood what I meant. Thank you.
– Tiago Aguiar
If you are concerned about this, you should not even use JSON, but a binary protocol, and omit everything that is not information at all. The rest is bullshit. Either use a standard exactly as defined, or do yours intelligently, to meet your requirements.
– Bacco