Comerford, Sean wrote:
> Is there any equivalent for PathParams if I want to support leaving one off
> and assuming a default?
>
If I were to guess, supporting @DefaultValue for @PathParam would
probably create more problems than what it solves (that is, a lot of
non-unique URI's).
> I guess my only option is to make season a query param instead of path
> param?
>
Remember that the principles behind REST is that URI's should be
descriptive and resources addressable. Personally I would be tempted to
reorganize your URI domain into something like this:
List of players:
/stats/players/
List of a players seasons:
/stats/players/{playerId}/seasons/
A players stats for a specific season:
/stats/players/{playerId}/seasons/{season}
A players stats for the latest season (have it forward or proxy to the
last season above)
/stats/players/{playerId}/seasons/latest/
If you don't have conflicts with other resources under /stats/ and if
you don't care super much about human readability, you could also
shorten it like so:
/stats/{playerId}/
/stats/{playerId}/{seasonId}
/stats/{playerId}/latest/
> Furthermore, and this is probably a dumb question but Iım slow on the
> upteake, in terms of proper RESTful design, is there a good rule of thumb on
> using a path param vs query param?
>
There's no one true answer, but query parameters are usually recommended
for algorithmic input only. That is, when it doesn't really have
anything to do with the identity of the resource and when there's no
hierarchal semantics behind. I.e. a background color of a chart, a
search item and similar dynamic stuff.
/Casper