Design patterns for objects in the REST API?

Question

I created a REST API with a preview of the WCF web API, and I want to create a library with the classes that you pass to this API (just to make life easier for .Net developers). These should be simple POCO classes without much functionality.

But on the receiver side, it would be advisable to add some functionality to these classes. The following is an example:

[WebInvoke(UriTemplate = "", Method = "POST")] public Supertext.API.Order Create(Supertext.API.Order apiOrder) { 

And this is an example of the POCO class:

 public class Order { public string Service { get; set; } public string OrderTitle { get; set; } public string Currency { get; set; } } 

Now, what is a good way to extend this class on the server side?
I think using a subclass will not work. Delegates
Actually there are two different versions of the class? One for clients and one for server?

What are other people doing?

Answer 1

The problem with adding extra features to this POCO class is that you turn it into a domain object. The nature of this domain object will now be limited by the fact that essentially this class acts as an interface definition in an operation. Changing the information about this class can lead to customer breakdown.

This is a cleaner model that allows you to save this class exclusively as a data transfer object, the sole responsibility of which is that it associates a wired format with objects and uses matching, for example AutoMapper , to map data from the DTO with the real domain object. The real domain object is completely under your control, and you can gladly reorganize it without threatening a cascading effect for your service consumers.