webapi推送消息html5,WebAPI DTO响应请求消息传递模式

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!

Talk1:

You should name them whatever you like. Just make sure you're consistent with naming things. User, UserDto and UserRequestDto are all perfectly fine examples.

Talk2:

Thanks. UserRequest and UserResponse seems to be good for me. I'll stick with that unless others have an idea. Would you say this is the request-response pattern, regardless of whether it's used in web api or used purely server-side and not used by web controllers and returned back to the front end as deserialized JSON data?

Solutions1

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.

Talk1:

Right that's what I was thinking too - a DTO should be used in web API because it goes back as JSON data to a page, whereas if you're operating purely server-side and interacting with a service layer of some sort, it's a request-response object and can be named that way instead. what do you think?

Talk2:

Whether it's purely server-side or not, I think naming a request-response object different names (i.e CustomerRequest/CustomerResponse) should only be done if they are different objects - if they are the same then that just produces unnecessary naming confusion.

Talk3:

these are definitely different classes (requests and responses). But would you say it's irrelevant to go with a DTO naming vs. a request/responses?

Talk4:

Ultimately, yes - the most important thing to do with naming is to make it consistent and convey meaning.

Solutions2

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.