Re: URI design, part 2

"Eric J. Bowman" wrote:
> 
> Making informed decisions about which constraints to apply, is making
> use of REST as a tool for long-term development.  It may not be
> feasible to apply all the constraints initially, if REST is truly what
> your system needs.  In which case your system design can account for
> this, becoming more RESTful over time, instead of painting yourself
> into a corner where the system needs re-architecting rather than
> implementing another constraint as an extension.
> 

This is why Roy's thesis is an invaluable tool, at least for me anyway
as I've been at this since '93 and had a front-row seat at the
transition from the old Web to HTTP 1.1 -- Roy's experience applying
his concepts to a system I was familiar with is included in his thesis,
which helped me to incrementally apply REST to my own work as I gained
understanding of it.  Now, I can confidently design systems today which
may be easily extended to be fully RESTful tomorrow.

So I really don't stress about the unRESTful aspects of my systems,
they're "by design" and will continue to work themselves out over time.
Which is exactly what you want from an architectural style, particularly
for the Web.  Successful websites tend to grow users over time, and it
ain't easy to chuck one system for another.  What's needed is a system
which uses progressively less resources per user, as usage increases.

(Just check out the shoddy uptime records of certain big boys on the
block to see how badly this desirable property is needed, and note that
they don't begin to implement REST.)

Using REST as a tool enables the development of such systems by allowing
the architect to chart a steady course, deciding which constraints (like
identification of resources) are crucial to get right from the get-go,
and which may be put off until they satisfy a cost-benefit analysis.

For example, most popular CMS software defaults to no-cache.  But this
doesn't really matter until you're starting to bump into the transfer
limits of your hosting plan, at which time you can implement caching,
after having some time to test the setup first. You can then fine-tune
your cache settings over time, and later integrate with a CDN.  This is
usually done ad-hoc, what I'm saying is that knowledge of REST can make
this go smoothly rather than being a comedy of errors (quite common).

If your system doesn't grow to need it, then you can probably do without
all the added development expense (plus complexity driving up long-term
maintenance costs) of implementing non-native caching on that CMS. REST
is your friend when it comes to planning for and managing these expenses
and complexities vis-a-vis your cashflow.  Budgeting for ho-hum websites
is easy; successful websites are another story entirely, where knowledge
of REST as a tool can be your competitive edge in funding growth from
cashflow instead of debt or outside capital while turning a profit --
instead of piling up red ink on wasteful infrastructure.

Yeah, I know.  That just isn't how things are done on the Web!  :-D

-Eric