Pressing the Limits of RESTful URI Design

I’m probably missing the boat here somewhere, but:

Say you’re modeling a beauty pageant (no pun intended).  JUDGES fill out BALLOTS on CONTESTANTS.   Each BALLOT has CATEGORIES: for example, “Poise”, “Swimsuit”, “Evening Gown”.

So far so good.  Easy enough.

Let’s say you want to extend the model to include AUDITOR functions.  The business rule is something like: “If a JUDGE returns a BALLOT that is missing entries for one or more CATEGORIES, the ballot is invalid and needs to be returned to the JUDGE.

So you’ve got a conceptual “bucket” that you can identify: bad ballots.  How do you model that RESTfully?

/ballots/bad

/ballots/bad/[id]

/ballots/bad/?category=[category]&judge=[judge]&competitor=[competitor]

??? Maybe this makes more sense the more I look at it.  I was initially thinking I needed to make all sorts of funky prefix URIs like /bycategory/ and /bycompetitor/, but just putting it in the query string makes sense for filtering entities, with no controller involved.

Score another one for thinking out loud via the blog

Advertisements

1 Response to “Pressing the Limits of RESTful URI Design”


  1. 1 Bastian September 21, 2008 at 11:43 pm

    Thanks for thinking out loud, I had the same doubts and you just confirmed my presumptions 😉
    Couldn’t you even put “bad” in the query, like /ballots/?type=bad&category=[category]&judge=[judge]&competitor=[competitor]
    ?


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s





%d bloggers like this: