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?




??? 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


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: Logo

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

TwitterCounter for @anthonyrstevens
Add to Technorati Favorites

RSS Feed

View Anthony Stevens's profile on LinkedIn

%d bloggers like this: