CODEWITHSUNDEEP
c#asp.net-web-apijson.netdto
user3520332
user3520332

Reputation: 241

WebAPI DTO Response-Request Messaging Pattern

I was reading a chapter in a book about the response-message pattern in C#, and when I recently came across a project that uses web API, and I noticed similarities and wanted some clarity on something.

In the book, the author's code wraps requests (in this case a CustomerRequest) in a class called CustomerRequestService, whose job is to process these requests (requests are nothing more than classes that have things such as search terms or properties relevant to the service finding a customer and do nothing else very thin/anemic(?) I guess you could say). The service returns a CustomerResponse, which wraps a customer class, a response from the server, and other pertinent information that would be used server-side to display results to the user.

Now, in the project i'm looking at, there are web pages that make ajax calls to web api controllers. The controller processes these requests and responds with their own responses. It uses json.net to do a deserialization.

You could say this is very similar. In the book, the author calls these request-responses, and in the code, they are named things like CustomerDto, CustomerResponseDto (DTO standing for data transfer object of course).

When I did searching online, it seems when I search for webAPI the naming standards revolve around DTO and not response/request.

Perhaps i'm splitting hairs or is this risible and irrelevant but was curious in scenarios like this what others are naming their request/response classes. I like the idea of calling everything Request/Response, even in a web api architecture, but i'm not sure if that's incorrect to name it like that, and I should call them Dtos.

The only difference I guess is that one thing is serialized and sent back to a webpage in the form of JSON, and the other remains as a class.

Thanks please let me know if I explained this correctly!

Upvotes: 2

Views: 3090

Answers (2)

ssthakur
ssthakur

Reputation: 61

In case you don't make separate request and response object, you will end up with :

1. Transferring the entire DTO, say for ex. comprising of 56 columns data.

2. Whereas your requirement is to just bind a dropdown list comprising key value pair, i.e., just two columns.

Alternatively, you could understand that whereas just 5-7 kb of data transfer is required, you are transferring 57 kb of data not of any use. This way you are merely wasting the bandwidth, adversely affect the performance of the entire application load on sever as well as network. In case you have optimized DTO which serves what you need, you end up with super fast application, that can load even on 2G connection in worst case scenario.

Upvotes: 1

rwisch45
rwisch45

Reputation: 3702

You can name them whatever you want (as always, be consistent), but to me using DTO instead of Request/Response makes more sense in this case. A DTO is used to transport data both ways - from client to server and vice versa. So it is used in both the request and the response.

Upvotes: 1

Related Questions