Date: 2005-01-16T15:07:53
Editor: OlegKalnichevski
Wiki: Jakarta-HttpClient Wiki
Page: HttpClientApiRedesign
URL: http://wiki.apache.org/jakarta-httpclient/HttpClientApiRedesign
no comment
Change Log:
------------------------------------------------------------------------------
@@ -329,4 +329,4 @@
One of the fundamental flaws of the 2.0 and 3.0 API is the rigid hierarchy of
classes representing HTTP methods. One has to extends all the classes in order
to implement a common behavior across all the available type of HTTP methods.
-A better approach may be to introduce common aspects shared by all types of
HTTP methods as a set of filters. HTTP method executor would be able to apply a
number of preprocessing filters to every request prior to sending it to the
target server and a number of postprocessing filters to every response
received. This design would allow for flexible introduction of crosscutting
aspects to all standard types of methods as well as custom ones without class
extension. For instance, filters may be employed to generate 'Host', 'Agent',
'Cookie' request headers and to extract cookies set by the target server from
'Set-Cookie' response headers. Similar approach may be used on the server side.
This design would enable decoupling of client- and server-side aspects from the
HttpRequest and HttpResponse primitives, thus making them more reusable.
+A better approach may be to introduce common aspects shared by all types of
HTTP methods as a set of filters. HTTP method executor would be able to apply a
number of preprocessing filters to every request prior to sending it to the
target server and a number of postprocessing filters to every response
received. This design would allow for flexible introduction of crosscutting
aspects to all standard types of methods as well as custom ones without class
extension. For instance, filters may be employed to generate 'Host', 'Agent',
'Cookie' request headers and to extract cookies set by the target server from
'Set-Cookie' response headers. Similar approach may be used on the server side.
This design would enable decoupling of client- and server-side aspects from the
{{{ HttpRequest }}} and {{{ HttpResponse }}} primitives, thus making them more
reusable.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
