Deprecating Binding.HTTP

[Luciano Resende <lu...@gmail.com>]

Binding REST was originally created as a copy of Binding HTTP and it
has been enhanced to a great extent without really removing any of the
native Binding HTTP functionality.

I was wondering what are people thoughts on deprecating the current
Binding.HTTP, and make the runtime to "proxy" all binding.http to
binding.rest.

Thoughts ?

-- 
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Re: Deprecating Binding.HTTP

[Luciano Resende <lu...@gmail.com>]

On Mon, Jul 12, 2010 at 12:11 AM, Simon Laws <si...@googlemail.com> wrote:
>
> Hi Luciano
>
> Not sure what you mean by deprecating here. Are you suggesting getting
> rid of binding.http altogether or keeping binding.http but using the
> rest binding code to implement it?
>

I just want to maintain one binding, instead of 2 as they are doing
pretty much very similar things.

> My concern about binding.http is that It's not clear (to me at least)
> what's going to happen with binding.http at OASIS. There is an old
> draft spec but I don't seen any discussion about whether this is going
> to be further developed or whether something else will be created in
> its place. Assuming that OASIS have a binding.http it would seem
> sensible for Tuscany to have an implementation.
>
> Simon
>

I think we have learned a lot during the implementation of the REST
binding, and it's a very good opportunity to provide OASIS an updated
draft with proposed changes based on these leanings. Having said that,
if we call this binding binding.rest versus bindinh.http and proxy the
"other binding"  to the concrete one, I'm fine with both ways.



-- 
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Re: Deprecating Binding.HTTP

[ant elder <an...@apache.org>]

On Mon, Jul 12, 2010 at 10:19 PM, Luciano Resende <lu...@gmail.com> wrote:
> On Mon, Jul 12, 2010 at 1:58 PM, ant elder <an...@gmail.com> wrote:
>>
>> I think i saw in some oasis meeting minutes recently where that there
>> was some movement on the http binding, i'll go ask.
>>
>
> Please let us know if there is any progress there.
>

All i can find is that a one of the binding meetings recently there
was some discussion about if binding.http could be done a bit later
and still be part of the 1.1 specs, and the answer was yes. So i think
the plan is still to progress it just it wont be immediately.

   ...ant

Re: Deprecating Binding.HTTP

[Luciano Resende <lu...@gmail.com>]

On Mon, Jul 12, 2010 at 1:58 PM, ant elder <an...@gmail.com> wrote:
>
> I think i saw in some oasis meeting minutes recently where that there
> was some movement on the http binding, i'll go ask.
>

Please let us know if there is any progress there.

> I think we should have some sort of http binding and leave the the
> rest binding to only deal with real REST style things. For example,
> REST operations shouldn't really have something like an opertaion or
> method name encoded in the url so somethng like
> http://localhost:8085/EchoService?method=echo&msg=Hello would be
> better on an http binding instead of the rest one.

We have been doing extensions to most of the specifications we have in
Tuscany, and this could fit well with a "extension"  to the http
binding. This is somewhat aligned with what is available in REST/Wink
to allow invocation of RPC operations via REST, the only difference is
that the URL pattern is somewhat different to allow portability
between bindings. Currently the RPC over GET support of very easy to
detach and is currently defined as a specific operation selector.

>Another example is
> back in 1.x we have both binding.jsonrpc and a wireformat.jsonrpc on
> binding.http don't we? That seems like a good thing to do again in 2.x
> with binding.http to me.
>

I have started another thread for this over the weekend, please send
your thoughts on that thread[1].

[1] http://www.mail-archive.com/dev@tuscany.apache.org/msg13194.html



-- 
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Re: Deprecating Binding.HTTP

[ant elder <an...@gmail.com>]

On Mon, Jul 12, 2010 at 8:11 AM, Simon Laws <si...@googlemail.com> wrote:
> On Sun, Jul 11, 2010 at 2:21 AM, Luciano Resende <lu...@gmail.com> wrote:
>> Binding REST was originally created as a copy of Binding HTTP and it
>> has been enhanced to a great extent without really removing any of the
>> native Binding HTTP functionality.
>>
>> I was wondering what are people thoughts on deprecating the current
>> Binding.HTTP, and make the runtime to "proxy" all binding.http to
>> binding.rest.
>>
>> Thoughts ?
>>
>> --
>> Luciano Resende
>> http://people.apache.org/~lresende
>> http://twitter.com/lresende1975
>> http://lresende.blogspot.com/
>>
>
> Hi Luciano
>
> Not sure what you mean by deprecating here. Are you suggesting getting
> rid of binding.http altogether or keeping binding.http but using the
> rest binding code to implement it?
>
> My concern about binding.http is that It's not clear (to me at least)
> what's going to happen with binding.http at OASIS. There is an old
> draft spec but I don't seen any discussion about whether this is going
> to be further developed or whether something else will be created in
> its place. Assuming that OASIS have a binding.http it would seem
> sensible for Tuscany to have an implementation.
>

I think i saw in some oasis meeting minutes recently where that there
was some movement on the http binding, i'll go ask.

I think we should have some sort of http binding and leave the the
rest binding to only deal with real REST style things. For example,
REST operations shouldn't really have something like an opertaion or
method name encoded in the url so somethng like
http://localhost:8085/EchoService?method=echo&msg=Hello would be
better on an http binding instead of the rest one. Another example is
back in 1.x we have both binding.jsonrpc and a wireformat.jsonrpc on
binding.http don't we? That seems like a good thing to do again in 2.x
with binding.http to me.

    ...ant

Re: Deprecating Binding.HTTP

[Simon Laws <si...@googlemail.com>]

On Sun, Jul 11, 2010 at 2:21 AM, Luciano Resende <lu...@gmail.com> wrote:
> Binding REST was originally created as a copy of Binding HTTP and it
> has been enhanced to a great extent without really removing any of the
> native Binding HTTP functionality.
>
> I was wondering what are people thoughts on deprecating the current
> Binding.HTTP, and make the runtime to "proxy" all binding.http to
> binding.rest.
>
> Thoughts ?
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>

Hi Luciano

Not sure what you mean by deprecating here. Are you suggesting getting
rid of binding.http altogether or keeping binding.http but using the
rest binding code to implement it?

My concern about binding.http is that It's not clear (to me at least)
what's going to happen with binding.http at OASIS. There is an old
draft spec but I don't seen any discussion about whether this is going
to be further developed or whether something else will be created in
its place. Assuming that OASIS have a binding.http it would seem
sensible for Tuscany to have an implementation.

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: Calculating the resource path, was: Deprecating Binding.HTTP

[Simon Laws <si...@googlemail.com>]

snip...
>>
>> BTW, that doesn't work so well when Tuscany is running in as Webapp, as
>> the HTTPBindingListenerServlet doesn't get the right resource paths.
>>
>> I think that the problem is in HTTPBindingListenerServlet.java:78
>> String path =
>> URLDecoder.decode(request.getRequestURI().substring(request.getServletPath().length()),
>> "UTF-8");
>> which, I guess, is trying to get the part of the request URI after the
>> http binding servlet path??
>>
>> That code seems to work OK in J2SE with an embedded Web container, where
>> there's no Web context root before the servlet path, but gets the wrong part
>> of the URI in a hosted Webapp, where there is a Web context before the
>> servlet path.
>>
>> I've tried to replace that line by:
>> String path = URLDecoder.decode(request.getPathInfo(), "UTF-8");
>> which returned the expected resource path, but I'm not sure what else that
>> change could break.
>>
>> Does anybody know for sure the intent of the original code? and why it
>> used getRequestURI() instead of just request.getPathInfo()?
>>
>> Thanks
>
> That change doesn't cause any build break, and nobody has come up with any
> more insight, so if there's no objections I'll push it from
> sandbox/sebastien/java/dynamic [1] to trunk.
>
> [1] http://svn.apache.org/repos/asf/tuscany/sandbox/sebastien/java/dynamic/
> --
> Jean-Sebastien
>

Looking at the line you reference:

request.getRequestURI().substring(request.getServletPath().length())

It would seem to be trying to get the resource path after the part of
path that identifies the servlet itself. Just by reading the docs your
replacement of this with getPathInfo() seems to be correct.
Description of getPathInfo() at [1] is

"Returns any extra path information associated with the URL the client
sent when it made this request. The extra path information follows the
servlet path but precedes the query string and will start with a "/"
character."

Interestingly looking at the description of getRequestURI() at [1].

"Returns the part of this request's URL from the protocol name up to
the query string in the first line of the HTTP request. The web
container does not decode this String. For example:
First line of HTTP request 	Returned Value
POST /some/path.html HTTP/1.1		/some/path.html
GET http://foo.bar/a.html HTTP/1.0 		/a.html
HEAD /xyz?a=b HTTP/1.1		/xyz "

The example "GET http://foo.bar/a.html HTTP/1.0 		/a.html" doesn't
seem to match the description of being from the protocol name up to
the query string. What do they mean by "protocol name" in this case?

The bottom line is +1 on the change.

Simon

[1] http://www.javadocsonline.com/api/apis/java-ee-sdk6.0.zip/api/javax/servlet/http/HttpServletRequest.html


-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Calculating the resource path, was: Deprecating Binding.HTTP

[Jean-Sebastien Delfino <js...@apache.org>]

Jean-Sebastien Delfino wrote:
> Jean-Sebastien Delfino wrote:
>> Luciano Resende wrote:
>>> Binding REST was originally created as a copy of Binding HTTP and it
>>> has been enhanced to a great extent without really removing any of the
>>> native Binding HTTP functionality.
>>>
>>> I was wondering what are people thoughts on deprecating the current
>>> Binding.HTTP, and make the runtime to "proxy" all binding.http to
>>> binding.rest.
>>>
>>> Thoughts ?
>>>
>>
>> Would that work with implementation.widget too? I'm asking because it 
>> looks like Widget components are using binding.http to serve their 
>> resources.
>>
> 
> BTW, that doesn't work so well when Tuscany is running in as Webapp, as 
> the HTTPBindingListenerServlet doesn't get the right resource paths.
> 
> I think that the problem is in HTTPBindingListenerServlet.java:78
> String path = 
> URLDecoder.decode(request.getRequestURI().substring(request.getServletPath().length()), 
> "UTF-8");
> which, I guess, is trying to get the part of the request URI after the 
> http binding servlet path??
> 
> That code seems to work OK in J2SE with an embedded Web container, where 
> there's no Web context root before the servlet path, but gets the wrong 
> part of the URI in a hosted Webapp, where there is a Web context before 
> the servlet path.
> 
> I've tried to replace that line by:
> String path = URLDecoder.decode(request.getPathInfo(), "UTF-8");
> which returned the expected resource path, but I'm not sure what else 
> that change could break.
> 
> Does anybody know for sure the intent of the original code? and why it 
> used getRequestURI() instead of just request.getPathInfo()?
> 
> Thanks

That change doesn't cause any build break, and nobody has come up with 
any more insight, so if there's no objections I'll push it from 
sandbox/sebastien/java/dynamic [1] to trunk.

[1] http://svn.apache.org/repos/asf/tuscany/sandbox/sebastien/java/dynamic/
-- 
Jean-Sebastien

Re: Deprecating Binding.HTTP

[Jean-Sebastien Delfino <js...@apache.org>]

Jean-Sebastien Delfino wrote:
> Luciano Resende wrote:
>> Binding REST was originally created as a copy of Binding HTTP and it
>> has been enhanced to a great extent without really removing any of the
>> native Binding HTTP functionality.
>>
>> I was wondering what are people thoughts on deprecating the current
>> Binding.HTTP, and make the runtime to "proxy" all binding.http to
>> binding.rest.
>>
>> Thoughts ?
>>
> 
> Would that work with implementation.widget too? I'm asking because it 
> looks like Widget components are using binding.http to serve their 
> resources.
> 

BTW, that doesn't work so well when Tuscany is running in as Webapp, as 
the HTTPBindingListenerServlet doesn't get the right resource paths.

I think that the problem is in HTTPBindingListenerServlet.java:78
String path = 
URLDecoder.decode(request.getRequestURI().substring(request.getServletPath().length()), 
"UTF-8");
which, I guess, is trying to get the part of the request URI after the 
http binding servlet path??

That code seems to work OK in J2SE with an embedded Web container, where 
there's no Web context root before the servlet path, but gets the wrong 
part of the URI in a hosted Webapp, where there is a Web context before 
the servlet path.

I've tried to replace that line by:
String path = URLDecoder.decode(request.getPathInfo(), "UTF-8");
which returned the expected resource path, but I'm not sure what else 
that change could break.

Does anybody know for sure the intent of the original code? and why it 
used getRequestURI() instead of just request.getPathInfo()?

Thanks
-- 
Jean-Sebastien

Re: Deprecating Binding.HTTP

[Jean-Sebastien Delfino <js...@apache.org>]

Luciano Resende wrote:
> Binding REST was originally created as a copy of Binding HTTP and it
> has been enhanced to a great extent without really removing any of the
> native Binding HTTP functionality.
> 
> I was wondering what are people thoughts on deprecating the current
> Binding.HTTP, and make the runtime to "proxy" all binding.http to
> binding.rest.
> 
> Thoughts ?
> 

Would that work with implementation.widget too? I'm asking because it 
looks like Widget components are using binding.http to serve their 
resources.

-- 
Jean-Sebastien