API changes to support request bodies

330 views
Skip to first unread message

Chris Kampmeier

unread,
Jan 25, 2009, 5:19:48 PM1/25/09
to FakeWeb
(crossposted from the Lighthouse account)

The last feature to add to FakeWeb before you could completely stub
out a RESTful web service is the ability to respond to PUTs and POSTs
differently depending on the content of their request bodies.

I already extended FakeWeb to support HTTP methods, which got us here:

FakeWeb.register_uri(:get, "http://example.com", :string =>
"response")

It'd be natural to just add a third parameter before the options hash:

FakeWeb.register_uri(:post, "http://example.com/users", "user
[login]=chrisk", :string => "User chrisk created!")

Something that's attractive to me about Ruby, though, is the way that
keys in options hashes make method calls self-documenting. In
practice, having many parameters (4, here) often strikes me as a code
smell of a method that needs refactoring. So something more like this
would be easier to understand, at a glance:

FakeWeb.register_uri(:post, "http://example.com/users", :body =>
"user[login]=chrisk", :string => "User chrisk created!")

However, we're currently using the third argument for only the
response, not the request -- it might more accurately be called
`response_options`. And that'll be parsed as one options hash with two
keys. So that gets confusing.

One solution would be to get all RSpecky:

FakeWeb.register(:post, "http://example.com/users").with_body("user
[login]=chrisk").and_respond(:string => "User chrisk created!")

Something like that would be kind of nice, actually. That'd require
some major architectural changes to FakeWeb, though.

Anybody have thoughts or suggestions? I wanted to get this out in the
open instead of just thinking about it by myself.

Thanks,
Chris
Reply all
Reply to author
Forward
0 new messages