locked
opposite of request/response design pattern? RRS feed

  • Question

  • User1610691276 posted

    Hello, the request/response design pattern is pretty standard in the implementation of modern enterprise and commercial web services.  Essentially, the parameters sent to the service are properties of a parent request object, like MyServiceRequest, and the data and information returned from the service are properties of a parent response object, like MyServiceResponse.

    So, is there a simple, standard, way to describe a web service, that does *not* use the request/response design pattern?  For example, a web service that accepts 3 different parameters, and returns a generic list of objects?  I would say this example uses simple types instead of a request/response design pattern.  Is there a more appropriate, general technical term to describe this type of web service that does *not* implement a request/response design pattern?

    Sunday, November 3, 2013 12:49 PM

Answers

  • User-484054684 posted

    I think what you are looking at is - "RESTful WCF Servies" where we can create services without SOAP envelops and the request and response wrappers.

    In REST pattern, we can create urls very simple and we can get the response something like POX or JSON formats as well.

    You may have to look at the below articles to understand above:

    http://msdn.microsoft.com/en-us/magazine/dd315413.aspx

    Please mark this as answer if this answers your question.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, November 4, 2013 3:47 AM
  • User-488622176 posted

    @dotnetterAMG123

    Entirely correct. Service architectures implement the request/reply mechanism. In some cases you do not need a reply. This simplified version is sometimes called "fire&forget".

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, November 5, 2013 8:07 AM

All replies

  • User-484054684 posted

    I think what you are looking at is - "RESTful WCF Servies" where we can create services without SOAP envelops and the request and response wrappers.

    In REST pattern, we can create urls very simple and we can get the response something like POX or JSON formats as well.

    You may have to look at the below articles to understand above:

    http://msdn.microsoft.com/en-us/magazine/dd315413.aspx

    Please mark this as answer if this answers your question.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, November 4, 2013 3:47 AM
  • User-488622176 posted

    Actually, REST is just another implementation of request/response.

    An alternative is publisch/subscibe where you reverse the logic (you do not request info, you get notified there is information available that might interest you). However I somewhere have the feeling your question is not about communication theory.

    What is your concrete problem/challenge?

    Monday, November 4, 2013 8:02 AM
  • User1610691276 posted
    Request-response, in its general sense, is a general computer protocol. However, in the web services domain, I think its meaning is more specific.

    For example, web services following the request-response design pattern in WCF will have a single request object and a single response object. With SOAP web services, the request object name usually ends with "Request" and the response object name usually ends with "Response."

    This naming convention, for requests, works differently with REST services due to protocol differences. But the response, should still be a structured, informative object, including data results and other supporting information.

    To answer Illeris, my goal is to explain to a client why a web service request should have a single request object, that encapsulates all the parameter info, and why the web service response, should be a wrapper that includes, not just the data results, but also other supporting information, like error details, if any.
    Monday, November 4, 2013 9:56 AM
  • User-488622176 posted

    @dotnetterAMG123

    Entirely correct. Service architectures implement the request/reply mechanism. In some cases you do not need a reply. This simplified version is sometimes called "fire&forget".

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, November 5, 2013 8:07 AM
  • Sunday, November 10, 2013 8:23 PM