I’m currently working on a project where I’m adding a new rest interface.
I’ve written a generic converter which converts the response into some objects.
Now i’m asking myself if I should convert those objects lets call them rest-interface objects into a new set of objects which would be my model. Most of the time, the data would be the same
but sometimes I would have a different representation of the data. E.g. the rest response would have a date as a timestamp but my model object would have a date object.
Another good thing would be, if I decide to change the rest interface into e.g. soap
my client code would only be dependend on the model objects and therefore I only have to
take care of the conversion. One downside would be that if I had to change something I need to do it within two places.
I’m not sure what the best practise is on this topic. I would also have an overkill of converting the rest-interface objects into the model objects (both ways for sending a request and for the response). Would be nice to hear some thought on this and maybe somebody knows some resources which explain this well.
Ever heard of “premature optimization”? Generally I wouldn’t be too concerned with performance when designing your application. Make sure you create readable code, that is easy to maintain, easy to extend in the future and generally future proof (e.g. switching from REST to SOAP should not create more hassle than necessary; this may be a more realistic scenario than you think at the moment). You should not go for a bad design, just because you “think” it may have better performance or because you think the “good design” could have poor performance.
Honestly, how many REST calls do you plan to make a second and how many millions objects are there within a single REST result? You create the best design you can and if you later on spot performance bottlenecks (too much CPU time being wasted, too much memory being wasted, etc.), then you start to optimize those bottlenecks away. If you are lucky, there will be no bottlenecks to begin with. If your main concern would be to create the fastest piece of code this earth has ever seen, you wouldn’t use Java to begin with, you would probably use the lowest level C possible, with inline assembly wherever you must to squeeze out the last drop of performance of your CPU.
So I would not model my design after the REST API, I would model my design the way I think it should be, the way it is easiest to code the rest of the application, and then write an importer/exporter that converts REST to my design and my design to REST. If you then switch to another technology, like SOAP, I just have to rewrite the importer/exporter, not the whole application.
There are exceptions, though: Personally I dislike date objects in any OO language. A timestamp is a perfect date representation IMHO, it is very easy to work with (comparison, adding/substracting an offset, etc.) and it has a very low memory overhead (just the number, usually a primitive, not even a memory allocation necessary). So unless you need date objects, as you cannot store or display this value as desired otherwise, I would keep a timestamp a timestamp and if you switch to SOAP in the future and it offers dates instead of timestamps, I would rather convert those to timestamps in the importer and back to dates in the exporter. Yet this is just me.