Rack as a client-side spec

Rack as a client-side spec

[Tim Carey-Smith]

Hey there,

I've been dealing with the painful API that is Net::HTTP and RestClient.

It seems to me that it would make sense for there to be a client lib  
which accepted a Rack environment and made a real HTTP request on the  
wire.
This would return the Rack response: [status, headers, body] and allow  
people to build tools which worked against a real web-service as well  
as a Rack app.

I've got an implementation for doing this using Mechanize as the  
backend, but it feels to weighty.
As I would see it, the library would allow the following:

> res = Rack::MockRequest.new(RackClient::HTTP.new).get("/foo",  
> "HTTP_HOST" => "example.org")

Which would result in 'res' containing the data at http://example.org/foo

Does this sound like a good idea? It means we can leverage the power  
of middleware on the client-side too.

> app = Rack::Builder.app do
>   # For http auth
>   use RackClient::Auth::Basic, "username", "password"
>   # For json serialization
>   use RackClient::JSON
>   run RackClient::HTTP
> end

This could probably be wrapped in a nicer API, but I think that shows  
the general idea.

Please tell me I'm missing something insanely stupid and this has been  
thought of and rejected before.
(Or not...)

Ciao,
Tim

Re: Rack as a client-side spec

[Daniel N]

[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]

On Tue, May 5, 2009 at 2:16 PM, Tim Carey-Smith <g@spork.in> wrote:

>
> Hey there,
>
> I've been dealing with the painful API that is Net::HTTP and RestClient.
>
> It seems to me that it would make sense for there to be a client lib which
> accepted a Rack environment and made a real HTTP request on the wire.
> This would return the Rack response: [status, headers, body] and allow
> people to build tools which worked against a real web-service as well as a
> Rack app.
>
> I've got an implementation for doing this using Mechanize as the backend,
> but it feels to weighty.
> As I would see it, the library would allow the following:
>
>  res = Rack::MockRequest.new(RackClient::HTTP.new).get("/foo", "HTTP_HOST"
>> => "example.org")
>>
>
> Which would result in 'res' containing the data at http://example.org/foo
>
> Does this sound like a good idea? It means we can leverage the power of
> middleware on the client-side too.
>
>  app = Rack::Builder.app do
>>  # For http auth
>>  use RackClient::Auth::Basic, "username", "password"
>>  # For json serialization
>>  use RackClient::JSON
>>  run RackClient::HTTP
>> end
>>
>
> This could probably be wrapped in a nicer API, but I think that shows the
> general idea.
>
> Please tell me I'm missing something insanely stupid and this has been
> thought of and rejected before.
> (Or not...)
>
> Ciao,
> Tim


I really like this idea.  I can think of a couple of things I'd like to use
it for already.

Cheers
Daniel

[-- Attachment #2: Type: text/html, Size: 2329 bytes --]

Re: Rack as a client-side spec

[Christian Neukirchen]

Tim Carey-Smith <g@spork.in> writes:

> Does this sound like a good idea? It means we can leverage the power
> of middleware on the client-side too.

It's awesome!

-- 
Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org

Re: Rack as a client-side spec

[Joshua Peek]

This sounds pretty cool.

I don't think anything needs to be done SPEC wise. We just need some
good tools here. Something to build raw http requests from an env
hash, and something to parse http requests (servers do this now).
Maybe a general tool like Rack::Utils.build_request(env) and
Rack::Utils.parse_request(io) would be a useful addition.

On Sun, May 10, 2009 at 6:35 AM, Christian Neukirchen
<chneukirchen@gmail.com> wrote:
>
> Tim Carey-Smith <g@spork.in> writes:
>
>> Does this sound like a good idea? It means we can leverage the power
>> of middleware on the client-side too.
>
> It's awesome!
>
> --
> Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org
>



-- 
Joshua Peek

Re: Rack as a client-side spec

[Daniel N]

[-- Attachment #1: Type: text/plain, Size: 934 bytes --]

Looks like Tim forgot to link his lib

http://github.com/halorgium/rack-client/tree/master

Cheers


On Mon, May 11, 2009 at 12:10 AM, Joshua Peek <josh@joshpeek.com> wrote:

>
> This sounds pretty cool.
>
> I don't think anything needs to be done SPEC wise. We just need some
> good tools here. Something to build raw http requests from an env
> hash, and something to parse http requests (servers do this now).
> Maybe a general tool like Rack::Utils.build_request(env) and
> Rack::Utils.parse_request(io) would be a useful addition.
>
> On Sun, May 10, 2009 at 6:35 AM, Christian Neukirchen
> <chneukirchen@gmail.com> wrote:
> >
> > Tim Carey-Smith <g@spork.in> writes:
> >
> >> Does this sound like a good idea? It means we can leverage the power
> >> of middleware on the client-side too.
> >
> > It's awesome!
> >
> > --
> > Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org
> >
>
>
>
> --
> Joshua Peek
>

[-- Attachment #2: Type: text/html, Size: 1669 bytes --]

Re: Rack as a client-side spec

[Bill Burcham]

This sounded like a great idea a few weeks ago. Now I've got a real
use case: I'm in the process of implementing a little ZIP-code lookup
service for a client (hits http://zip4.usps.com/zip4/welcome.jsp) and
I'm wishing I had a (client-side) middleware for caching those
responses.

Re: Rack as a client-side spec

[Simon Rozet]

On Wed, Jul 1, 2009 at 8:00 PM, Bill Burcham<bill.burcham@gmail.com> wrote:
>
> This sounded like a great idea a few weeks ago. Now I've got a real
> use case: I'm in the process of implementing a little ZIP-code lookup
> service for a client (hits http://zip4.usps.com/zip4/welcome.jsp) and
> I'm wishing I had a (client-side) middleware for caching those
> responses.
>

Checkout cacheability which hacks RestClient to use Rack::Cache
http://github.com/cryx/cacheability

-- 
Simon Rozet <simon@rozet.name> http://atonie.org

Re: Rack as a client-side spec

[Bill Burcham]

[-- Attachment #1: Type: text/plain, Size: 401 bytes --]

Ooh cool thanks Simon. I have a little (familiar) problem now: the service
I'm hitting is form-based. So I have to POST to it. That breaks the rules of
course since POST is supposed to create resources and as such is not
cache-able according to HTTP.
So this sort of caching doesn't fit neatly into REST orthodoxy. An expedient
answer of course is just to fork cacheability. Is there a better answer?

[-- Attachment #2: Type: text/html, Size: 437 bytes --]