Two REST tips for tackling tricky resource examples

After my post a couple of days ago about the first thing you should know about REST, a friend emailed me with this feedback:

Nice post. It was something I was thinking about just recently and I think I’m guilty of making these mistakes. The example which confused me was verifying a password. I wasn’t sure what HTTP method to use or what the resource was. The request needs to contain a password but doesn’t expect any response other than a 200, does this mean GET is inappropriate?  It doesn’t update anything, unless of course it fails in which case it may update a failed login counter or lock the account. Does this rule out PUT and POST?

Young man in a very uncomfortable hammock, trying hard to pretend to have a REST.Here’s the response I sent him (fleshed out with a little more detail for this blog)…

REST can be easy and REST can be hard

Yep, the examples in my blog were the easy ones. Plenty of hard ones will crop up, where the resource on the server you want to manipulate is not immediately obvious, like the one you’ve pointed out, or where coming up with a good set of URL patterns is not straightforward. As with all things that aren’t easy, spending some extra time on it is usually worth the effort.

Think like a REST Server

I think what can help is to try and think less about what the client is doing (“verifying a password”) and more about what’s happening on the server side. Continue reading

RxJava Threading Examples

I recently used RxJava while creating an add-on for Stash, the Git repository management tool from Atlassian. The plugin’s called “Who’s the Expert?” and it analyses commits to a repository to help answer two questions:

  1. “Who has contributed the most to this project over the past few years?” and
  2. “Who has made the most significant changes in recent months?”

A Problem Worthy of RxJava’s Attention

This picture of water drops on the threads of a spider web reminded me of the bubble diagrams the RxJava team uses to explain how values move through the libraryIn order to achieve this, the plugin has to process a lot of data: it pulls all commits on the default branch for the last 2.5 years and analyses the content of every single one. I knew two things about this code in advance: first, there were going to be a lot of steps to go from a repository name to a leaderboard of the most influential committers, and second, I was pretty certain I’d need some multi-threading mojo in order to get it to perform in an acceptable time frame.
Continue reading