Thanks a lot for your reply, Nathan. It answers my questions very clearly. The IBM article is also very useful. I will have to keep going back to it any time I forget what REST is when I get bogged down by implementation details. :D

It probably would be best to review the code yourself and make no compromises. Unfortunately, I am one of "them" and have seen stuff that would probably make any sane programmer want to shoot him(her)self, but I have also seen that the above method works. I would recommend trying that, if possible.

I am not sure this is the correct forum, so please excuse me if I am posting in the wrong forum. I am trying to understand the best practices in building SOA applications. Unfortunately some of are not so black or white and need experience to figure out the right approach. Here are some of them: 1) Let's say I am building a REST service for extracting data from various tables. Is it considered best practice to return the whole entity or just the necessary values? The target might be multiple platforms (web, windows and mobile apps). 2) Also, is it RESTful to join entities from multiple tables and return it as a single entity? 3) When joining entity types, should only the necessary values be returned or is it better to form a compound type composed of the basic types? Example: Consider a REST service that return's an employee's address. The address is composed of the types Apartment, Street, City and Zip Code. Each type has properties (eg: Street has starting and ending lat-lon). In the client only the address <apt number> <street name> <city code> <zip code> is required. How should the return type of a REEST service call be structured? (It would also help if anyone can provide the recommended URL syntax for this as well. Should there be a specific call like "GetEmployeeAddress" or something like ' <service URL>/Employee/<emp ID>/Address' ?) I would be very grateful for suggestions for reading materials in this topic. Thanks in advance. :)