[httpclient] [proposal] Remove the "httpclient/methods/Url*Method " classes

[Jeff Dever <jd...@nortelnetworks.com>]

[PROPOSAL]

Delete the 6 Url*Method classes and reimplement the functionality in a way
that makes sense.


[REASONING]

The httpclient/methods package has the following classes:
http://cvs.apache.org/viewcvs/jakarta-commons/httpclient/src/java/org/apache
/commons/httpclient/methods/
DeleteMethod
GetMethod
HeadMethod
OptionsMethod
PostMethod
PutMethod
UrlDeleteMethod
UrlGetMethod
UrlHeadMethod
UrlOptionsMethod
UrlPostMethod
UrlPutMethod

Each *Method has a Url*Method wrapper.  I was not around when these were
added, but I think that these are a really bad idea.  I would guess that
they were to make up for the fact the the constructors for the *Method
classes would only take a path as a String, but sombody wanted to pass in a
full URL String, so wrappers for every *Method were created.

I would say that this was a bad design decision, for several reasons:

1) The behaviour that these classes represent could have been implemented
without change to the API.  The constructor of HttpMethodBase could have
been modified to allow either a path or a full Url to be passed in, and to
parse it appropriately.  Or another constructor that takes a URL object as a
parameter.

2) The number of method classes has been multiplited by 2.  This sets up a
very bad pattern for future changes in an API and I would consider it
serious "API Bloat".

3) The Url*Methods are all broken: they take a String URL as a parameter,
but ignore the protocol, host and port.  All that is parsed out is the path
and querystring.  This is completely unexpected behaviour.


They were added in February this year and have never been included in a
tagged build.  Therefore there is no need to depricate them and they can be
removed according to the Commons Versioning guidelines.  I should stress
that now is the time to remove them, before the next 2.0 milestone, as they
will be more difficult to change afterwards (and they really don't work).
http://jakarta.apache.org/commons/versioning.html

Re: [httpclient] [proposal] Remove the "httpclient/methods/Url*Method " classes

[Davanum Srinivas <di...@yahoo.com>]

+1 to removing them.

Thanks,
dims

--- Jeff Dever <jd...@nortelnetworks.com> wrote:
> 
> [PROPOSAL]
> 
> Delete the 6 Url*Method classes and reimplement the functionality in a way
> that makes sense.
> 
> 
> [REASONING]
> 
> The httpclient/methods package has the following classes:
> http://cvs.apache.org/viewcvs/jakarta-commons/httpclient/src/java/org/apache
> /commons/httpclient/methods/
> DeleteMethod
> GetMethod
> HeadMethod
> OptionsMethod
> PostMethod
> PutMethod
> UrlDeleteMethod
> UrlGetMethod
> UrlHeadMethod
> UrlOptionsMethod
> UrlPostMethod
> UrlPutMethod
> 
> Each *Method has a Url*Method wrapper.  I was not around when these were
> added, but I think that these are a really bad idea.  I would guess that
> they were to make up for the fact the the constructors for the *Method
> classes would only take a path as a String, but sombody wanted to pass in a
> full URL String, so wrappers for every *Method were created.
> 
> I would say that this was a bad design decision, for several reasons:
> 
> 1) The behaviour that these classes represent could have been implemented
> without change to the API.  The constructor of HttpMethodBase could have
> been modified to allow either a path or a full Url to be passed in, and to
> parse it appropriately.  Or another constructor that takes a URL object as a
> parameter.
> 
> 2) The number of method classes has been multiplited by 2.  This sets up a
> very bad pattern for future changes in an API and I would consider it
> serious "API Bloat".
> 
> 3) The Url*Methods are all broken: they take a String URL as a parameter,
> but ignore the protocol, host and port.  All that is parsed out is the path
> and querystring.  This is completely unexpected behaviour.
> 
> 
> They were added in February this year and have never been included in a
> tagged build.  Therefore there is no need to depricate them and they can be
> removed according to the Commons Versioning guidelines.  I should stress
> that now is the time to remove them, before the next 2.0 milestone, as they
> will be more difficult to change afterwards (and they really don't work).
> http://jakarta.apache.org/commons/versioning.html
> 
> 


=====
Davanum Srinivas - http://xml.apache.org/~dims/

__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>