I'm receiving objects in JSON, and currently the app only uses a small amount of the properties I receive. I'm wondering which of the following is best practice, or simply generally advised.

  • Would it be better for the server to actually send partial objects (smaller data)? That way, I wouldn't have to worry about mapping more or not.
  • Should I map the complete object in my model, knowing I won't need all those properties, but at least they'll match the server?

Right now, I've decided not to, since there could always be change, and I don't like having "useless" code, since I believe this is not in the "make it future proof" category.


If you have exactly one app, and the server sends the JSON only to this app, you should go with @simon's advice. However, when you have a dozen apps, each of them needs a different part of the data, then tailoring the JSON to each of them (so making twelve different APIs, one for each app) might become cumbersome, inefficient and errorprone. If that's the situation, you will have to make a trade-off between network optimization and keeping the API maintainable.

For the latter case, two or three different reusable "views" to your business object may be a practical compromise. Moreover, if you use a generator to create the JSON and the model in your app from some meta model or data schema, then letting it generate some extra attributes you do not need immediately is not a violation of YAGNI. For a generator it does not make a big difference if it generates 10 attributes or 20 - it may be more effort the make the generator so flexible it can generate different APIs, and then it is questionable if that is more flexibility than you really need .

EDIT: There is another possible approach: each app could tell the server in some kind of query exactly which attributes it needs, and the server delivers that in a generic manner. A quick google search reveals there are already JSON query languages available for this scenario, see for example this former SO post or JSONiq.


Just map and send what you need. This keeps the code readable and reduces network traffic. However, make your code structures so that they are easily extendable when they have to be changed.

Some principles which apply:

When there is a possibility that you want to extend your API, you should consider versioning from the beginning so that your REST API is easily extendible without breaking functionality for existing clients.

  • 1
    Also keep a version number: on the API level at least, or even in every message. This will let you figure which properties to expect from which message. It will prove invaluable when you'll have to migrate to an updated version of the protocol / property set. – 9000 Mar 15 '16 at 16:19

This is a "bottom up" versus "top down" issue.

In most cases, I'd take the "bottom up" approach and map just what I need as I go, especially if it is not clear just where the application will go. Then you want to keep things open ended.

The "top down" approach works best when the number of use cases is limited, and the system is basically "closed." Then the argument is "If I do everything I need to this one time, I won't need to do anything else again." A little extra effort now will save a lot of pain in the future. That would be when it's unlikely that any new "paths" will take you outside of what you've done, if you did it "all" the first time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.