Verbs and Nouns, Methods and URLs

Following the concept of HTTP as the Web’s pidgin language, it’s interesting how often the only two verbs in this language, GET and POST (PUT and DELETE are making a comeback, but still pretty rare), are interchanged. It seems many developers simply use POST whenever there’s a form and GET when there’s a link – not the way they’re meant to be used.

Here’s how it is: GET is when you want to get some data from the server. POST is when you want to change the data in the server. GET is for read. POST is for write.

It’s important to keep data-changing actions behind POST – common mistake is to make a “Delete” GET link and then get it accidentally activated when a bot crawls your site (if you didn’t follow that particular issue – Rails team eventually realized it was their mistake and added support for POST links).

It’s equally important to make various reads via GET, because that way you’re allowing people to link to specific data in the site. A common scenario: a simple search field behind POST forces users to ask their friends to “go to this URL, then search for “x”…” instead of simply sending them a link to the search results. Naturally it gets worse in more complex forms, with several variables.

Speaking of URLs, seems to me deep URLs – pointing to specific content on the site – aren’t getting the care they deserve. Used to be that HTML frames hid the URL for a specific data item or view from the user, now you often get this in AJAX interfaces. It’s a shame, since deep URLs are really the most basic and most used Web API. It’s the link to an article, or product or comment to a story that people send to their friends.

Back in Notifyr (yeah, I’m going to milk every drop of Webapp examples material from this little app) I put in a short explanation page on how to build a simple URL to subscribe to a specific account. It’s cool to see folks using this to create their own “Subscribe to my photos” link in their profiles and blogs. is not related to

A website called “” popped up recently, offering a similar yet different service to my own Just wanted to make sure there’s no confusion: I have no connection whatsoever to that site.

The RSS Tap

It just occured to me that many things I been thinking about feeds can be summarized as “RSS Tap“, and so I’m rushing to coin this phrase (hey, it worked nicely for the guy who came up with “AJAX” ;))

“RSS Tap” (or, well, “RSS/Atom Tap”) is like RSS push, but more gentle. For example, you’re subscribing to some article’s comment feed: you want to read future comments, but you don’t really need each comment delivered immediatley to your aggregator as it’s published. Probably you don’t even want to make a new feed subscription in your aggregator just for these comments. You just want to be notified when there’s some new comments to read there – but not every hour, and without having to register anywhere, and without getting any future spam.

So RSS tap is like a kinder, gentler RSS push. But it is a tap – it does actively get to you, rather than you having to pull the info yourself (what we used to call, in less sophisticated times, “visit the web page again”).

As phrase coiner of “RSS Tap” – verified by a Google search! – I hereby declare Notifyr an RSS tap application: you don’t need to register. You don’t need to use a feed aggregator at all. You get messages only if there’s new content, and not more than once a day. You turn it off by one click on the link at the bottom of the email, and switch it on again at another place with one click of the bookmarklet (by now I achieved about 3:1 blog-to-code lines ratio on that little app)

(BTW, being non-native English speaker I might be missing something here: when I say tap I’m thinking of someone tapping your shoulder to get your attention in a crowded place. Maybe also an old water tap that releases a few drops every now and then. Is there a more fitting word I should use?)

On Notifyr

I built Notifyr couple months ago. I actually got off my ass and did it in order to learn Ruby on Rails, and at the same opportunity scratch a little itch (no pun please) I had about sharing Flickr photos.

I was travelling a bit at the time and was getting tired of emailing friends & family whenever I returned and uploaded new trip photos to my Flickr page. RSS could have solved this, but almost no one (that’s among people with a life) uses RSS. I considered RSS to email gateways, like RssFwd, but these usually send an email for every new item – 20 new photos from my last trip would mean 20 emails to each contact.

So, I wrote a simple app which monitors a Flickr page’s RSS once a day and, if new images were published, sends one email per contact: “I got new photos in my Flickr page”.

Next was the registration issue. I really dislike having to register to use sites – there’s probably no way around this for email services or banks, but for tiny apps like Notifyr it’s absurd to have to register, wait for confirmation mail, remember a password etc. My solution was basically adapted (read “lifted”) straight from RssFwd – no registration at all, every email sent contains an easily-filterable sender address and an unsubscribe link with a unique string.

No one can find out what pages you’re monitoring without breaking into your email account (or into, or subscribe you to something you don’t want without being easily deleted, nor unsubscribe you without figuring out the hash string. I believe this is good-enough-security: obviously it can be compromised, just like your bank’s website can. I believe the Evil Genius Cracker would rather concentrate her powers on the latter first.

An added bonus of having no registration is solving the “Grandma Case”: I wanted people to be able to send a link to their non-geek contacts that will subscribe them to their Flickr page, or even subscribe them without sending a link so that, for example, you could have your grandmother get an email whenever new family pictures are uploaded. You enter her email and your photo page URL, and it starts working. She never has to register or even visit at all.

Building these links is quite easy – the examples show you how to build URLs (or “Access Via REST API” if you like that sort of stuff) by yourself. I’m work on the assumption here that, while Notifyr users may not be computer geeks, they can figure how to alter a URL by themselves. Happily, it seems to have worked out well so far, and indeed people have been creating their own Notifyr links on their blogs or Flickr profiles etc.

Finally, you might wonder about spammers using Notifyr. This is simply handled by making it a lousy tool for spamming. Emails get sent at most once a day. Emails don’t contain the actual photos are other content (text etc) that can be influenced by the photo page’s owner. Emails do contain an unsubscribe link. A spammer would have to publish his content as Flickr images – and be vulnerable to Flickr’s own content editing. So, rather than make it hard for spammer, I just made it useless for them. If this is not Zen I do not know what is.

Well, that’s Notifyr. Hope you might find it useful. There’s probably more text here than in the actual code already, but that’s how it goes – us lazy people know that talking a lot about what we’ve done keeps us from having to do more of it.