Home | Forum | Unread | Sign in | Sign in
Wirebird
Forum
KarenCravens
Karen Cravens

Tue

Jul 1
2008

17:30Z

REST anti-patterns

Stefan Tilkov wrote an interesting article listing some REST anti-patterns:
http://www.infoq.com/articles/rest-anti-patterns
Unfortunately, I make use of a few of these... though not without consideration.
#2: Tunneling everything through POST.
It's more commonly called "overloaded POST," and the problem is, it's still necessary if you support the browser as a REST client. (Decreasingly so, but still.) PUT and DELETE are not predictably, reliably supported.
Of course, Wirebird is perfectly happy to accept a real PUT or DELETE, so maybe that doesn't count. It still follows the idempotency rule, so a fully-compliant client could use a PUT confidently without having to put its trust in a mere overloaded-POST with a "method" parm set to "put".
#4: Ignoring status codes.
Purity yields to pragmatism again. Wirebird used to issue a full suite of error codes, until I realized that comment spammer robots don't recognize them. Only a 404 or 403 makes (some of) them stop hammering on forms. So the real errors are commented out, or it issues mutant things like "404 409 Conflict" and such. This makes me grumpy ("oh look, yet another perfectly useful Internet feature ruined by spammers"), but as the debug levels get turned down and performance improves, I'll probably turn the real status codes back on, and focus more on blacklisting griefers. Or maybe I'll just be more proactive and buy a sniper rifle.
#5: Misusing cookies.
Only a little. The authentication cookie, while it's called a session id, *only* holds a session ID... at the moment, essentially a temporary password. There again, that's because not very many browsers can handle authentication well. Eventually, for smarter browsers and other clients, there will be a proper authen protocol, and the form-based cookie stuff will be a fallback only. I don't think it'll be a really serious matter until Wirebird is less obscure; right now there's no real value in hacking someone's account, especially as long as we accept mailing-list posts. (Want to spam a mailing list? Just forge the email address of one of its authorized senders. No password required.)
On the plus side, I'm feeling relatively good about how I handle the other five anti-patterns.
Permalink | Thread | Add reply
KarenCravens
Karen Cravens

Sat

Sep 15
2007

02:06Z

jQuery and HTTP responses

You may remember me griping in July about Mochikit not handling the full range of HTTP responses correctly. I griped on the rest-discuss list about it, and was referred to jQuery.

And I've been pretty impressed with jQuery overall, and I'm writing the Javascript version of logging in/registering (because the HTML-only version is tedious). A successful login POSTs to /profile/{username}/session, and gets redirected (via 303 See Other) to /profile/{username}.

And guess what? jQuery's .ajax treats a 303 as... an error.

Bah.

Permalink | Thread | Add reply
KarenCravens
Karen Cravens

Mon

Aug 20
2007

23:47Z

Inlining forms!

"display: inline" was the property I was looking for in my first post here. I had somehow decided to try inline-block (no, I don't know why) and concluded that that approach didn't work with forms.

I still don't have it displaying with underline ("text-decoration: underline" isn't triggered, apparently), and I still have some issues with horizontal spacing in IE, but at least it's inlining everything.

Of course, even inline there's actually not enough space on the post footer for all the options, but that's a different issue.

Permalink | Thread | Add reply
KarenCravens
Karen Cravens

Sat

Aug 18
2007

21:35Z

Put/Delete not fully functional

A little bird told me that PUT and DELETE aren't fully/reliably supported in all browsers, even in JavaScript. This is news to me (and I don't know what "quirks" come up), and makes me sad since I don't plan to write any Wirebird client apps outside of the browser (or Thunderbird, I suppose).

Of course, by the time Wirebird's done, it probably *will* be supported.

Permalink | Thread | Add reply
KarenCravens
Karen Cravens

Wed

Aug 8
2007

13:56Z

Form validation

Not strictly REST, but I had to say something:

http://letmehaveblog.blogspot.com/2007/08/easy-client-side-web-forms-va lidations.html

The jQuery.YAV plugin accepts my usual personal email address, unlike about 90% of the form-validators out there. Huzzah!

Yes, validating email is black magic. No, being too restrictive is not better than being too permissive (at least if you want *me* to buy from your online store). Yes, a "+" is legal in the localpart of an address. No, I will not get a Yahoo email address just to buy from you.

Permalink | Thread | Add reply
KarenCravens
Karen Cravens

Sat

Aug 4
2007

19:11Z

RESTful HTML (and CSS)

I find myself asking HTML questions in the REST mailing list, which is probably not terribly appropriate. But I'm discovering my HTML knowledge is not exactly standards-compliant, in large part because my past HTML work has been fairly static.

I'm also slightly more constrained than a lot of REST programmers, with my self-imposed restrictions of "usable by dumb browser," which means not using JavaScript to "cheat" (until later).

So I'm faced with things like using forms instead of links (because the browser can't do a POST/PUT/DELETE with a link), which means sometimes figuring out how to put a "naked" submit button out there, and (here's the hard part) fit it into the layout of a page. So far as I can tell, forms are unavoidably block-level critters, which means they stubbornly want to be on a line by themselves. This means using float:left to get a row of them and (as can currently be seen in the mailbox mark (un)read buttons) sometimes they still won't properly stay on the baseline.

As I run across workarounds, or figure them out myself, I'll put them here. Also, though I haven't gotten Wirebird in a repository yet, it's open source (Creative Commons Attribution-ShareAlike, though I'll probably also GPL and Artistic it as well) so you can swipe any bits of HTML, CSS, or JS that you find handy (that isn't otherwise noted in the comments as belonging to someone else, at least).

Permalink | Thread | Add reply
KarenCravens
Karen Cravens

Tue

Jul 17
2007

23:18Z

REST clients in Perl

I've been getting some search hits here for folks looking for Perl and
REST, and generally not finding what they want (at a guess). Partly
that's because hey, there's only one entry in this subcategory. But
most of my REST+Perl work is going to be on the server side, so I
probably won't have much to say about Perl-based clients, which seems
to be what most of the searching is for. 

Really, there's nothing all that special about writing clients for a
REST service. Unless you consider "RFC-compliant http" to be special,
which I guess it is. 

This means you have to do things like support PUT and DELETE in
addition to GET and POST. I support overloaded POST in Wirebird, since
I intend to support vanilla browsers, but not all services will do
this. 

You may also need to set your headers for Acccept and Accept-Language. 

It also means you have to pay attention to the http status code you get
back. 

LWP::UserAgent can do all these things. LWP::Simple can do all, I
think, except setting the headers (which is fine if you like the
defaults, whatever they are... */* for Accept, at least).
Permalink | Thread | Add reply
KarenCravens
Karen Cravens

Wed

Jul 11
2007

15:00Z

Solving the click-depth issue

I think my answer is going to be to sort-of-overload the group and topic 
levels, which I was doing pre-REST.

Right now, if you look at
http://forum.phoenyx.net/group/
you'll see (with a webforum template) *all* the topics, including their 
last-post and post-count information. Pretty much a standard top-level 
webforum page.

I think it's still RESTful... it's the representation of a "meta-group."
Permalink | Thread | Add reply
KarenCravens
Karen Cravens

Tue

Jul 10
2007

02:19Z

The machine side

If you want to play with the machine side of things, you can replace
the "html" extension with "js" for a JSON version, or "dump" for a Perl
Data::Dumper format. I don't expect anyone to write a client that uses
the Perl stuff, but it's useful for debugging and hey, if you want to
use it, I don't see a reason for it to go away. 

To be properly RESTful, Wirebird will need to actually pay attention to
the "Accepts" headers (technically it does but the extensions override
it for debugging purposes, which will be reversed for production). You
can test this by leaving off the extension and specifying Accepts... I
haven't yet, so if you do this let me know. 

Of course, I shouldn't actually post this until I have all the stuff
cleaned up and standardized. Right now, you'll be able to see some
RESTlessness in that I don't have all the links coming through
properly, things like that (because I originally assumed constructed
URLs, in the pre-REST days, but REST calls for explicitly passing
them). 

Also, trivia note: I got a hit here by someone from apple.com, using
Firefox on OS X, googling for "perl restful." Read into that what you
will.
Permalink | Thread | Add reply
KarenCravens
Karen Cravens

Fri

Jul 6
2007

01:57Z

HTTP responses

REST makes use of the full range of HTTP response codes, so as to avoid
clients having to parse the returned entity body to try to figure out
what the server did with your request. This was all pretty new to me
(and some of my learning curve is still embedded in Wirebird;
fine-tuning the codes is on my to-do list), but at least I knew the
basics: 2xx means success, 3xx means something moved, 4xx means you did
something wrong, 5xx means the server did something wrong. 

Unfortunately, the current version of Mochikit (which I had just about
settled on) isn't quite so savvy: it apparently doesn't understand
success codes outside of 200. 

I'm not used to having to check for this sort of support; I'm glad
someone on the Mochi forum mentioned it before I got too committed.
Permalink | Thread | Add reply
KarenCravens
Karen Cravens

Mon

Jul 2
2007

15:48Z

Web service vs. web site

The current problem I'm having with Wirebird is deciding how to present
resources so that they're convenient for both machines (standalone
clients or advanced JavaScript on our own pages) and humans browsing
the site.

The main resource structure looks like this:

Categories,
which are a collection of groups.

Groups (=mailing lists, =blogs),
which are a collection of topics.

Topics, which are a collection of
pages (posts, replies, and eventually wiki pages).

The problem is
rather visible on the wirebird.com pages right now... to get to any
content, you go to the main page, then you go to a category, then a
group (where you get to see a little content, in the form of the
most-recent-post preview in each topic), then the topic where you get a
list of threads, and then, finally, you can click on a thread and hey,
there's finally some actual *content*.

This part is a little better...
main page, category, and the group has the content since topics are a
little downplayed in blog style.

And if you look at the Phoenyx forum:
http://forum.phoenyx.net/, you see a more webforumish setup, but that's
the less-RESTful version of Wirebird. It also starts to break down as
you get more and more content - the Phoenyx is small enough to get by
with all the *topics* on the main page (especially since all the groups
are single-topic), but that will get overwhelming with a large site.
And that's important: for the machine side, we don't want to have
clients that assume there are going to be (for instance) topic- or
thread-level pieces in the category or group resources, and have that
go away when the site gets larger.
Permalink | Thread | Add reply
KarenCravens
Karen Cravens

Sun

Jul 1
2007

18:10Z

RWS and Perl

Okay, if someone is porting the /RESTful Web Services/ examples to
freakin' Smalltalk, someone is clearly going to have to do the same
thing for Perl.

http://www.crummy.com/2007/06/29/2
Permalink | Thread | Add reply
KarenCravens
Karen Cravens

Sun

Jul 1
2007

16:26Z

What is REST?

REST stands for REpresentational State Transfer.
http://en.wikipedia.org/wiki/Representational_State_Transfer

A RESTful
web service is particularly easy to write clients for, for several of
reasons:

No application/client state is stored on the server. If
something unexpected happens during a server/client conversation, the
client doesn't have to worry about re-synching to the server's state.
Its logic can therefore be much simpler.

The interface is very
standardized - actions are limited to HTTP methods, and URLs represent
resources (nouns).

URLs are well-connected.

So, for instance, a
Wirebird client can visit a new Wirebird site, and discover (via a
standard GET) the categories on that Wirebird (via the
well-connectedness). It can then fetch the groups in each category, and
the topics in each group, and the posts in each topic, based on the
links in each response.

Using the standard HTTP methods means that the
client can create, edit, and delete items in a standard manner (a
well-written REST service is self-documenting, though we'll publish API
documents anyway.)

REST is chiefly aimed at the "machine web," but
Wirebird is intended for consumption by the original client app as
well: the human-directed web browser. A certain amount of client-side
scripting will improve the user's experience, but one of Wirebird's
goals is to operate in even the most basic browser, without scripting
(or with scripting turned off).
Permalink | Thread | Add reply