the value of 3xx

in my reading of the rest-discuss list and digging around in general, i am starting to realize that the 3xx response code can be very valuable in dealing with proper handling of situations.



301 - moved permanently

does iis handle this at all?



302 - moved temporarily

shuttle the request to another uri for this moment - iis handles this one (not always well)



303 - see other

commonly used to redirect POST to another page - not using this at all, might be quite handy



304 - not modified

the resulting request has not changed since you last asked - i use this alot now



gotta get my hands into the 303!

stlled, but learning

i'm kinda stalled on upgrading my rest-ian framework. the initial templating system is working, but i need to iron out and sand off the rough edges on my security implementation for embeded templates (templates calling templates...).  it should be working fine in a few days.



in the meantime, i helped jesse implement another feature on his web site. although he is not using the 'full-blown' rest-ian model, most of the recent changes i've implemented for him use rest-like patterns and lots of xml/xslt work. he's actually getting the hang of working with xsl transformations, too.



finally, i stumbled upon a couple related items on a rest email list this week and it's got me thinking:





Megginson Technologies: Quoderat

Lost Update Problem. This doesn’t have to do with REST per se as much as with the choice not to use resource locking, but since REST people tend to like their protocols lightweight, the odds are that you won’t see exclusive locks on RESTful resources all that often (it also applies to some kinds of POST updates as well as PUT).

Reliable delivery in HTTP

Achieving reliable delivery in HTTP is not difficult. It takes a little bit of understanding of how HTTP works and what reliable delivery means.

both of these items point out common problems with any remoting/async system. and they both have very simple solutions!  i really like the version id solution for the lost update. i am still working on the details of reliable delivery using POST (or RPOST).



but they bothremind me that there are a number of additional things to consider before i claim a 'complete' framework!

more on hypermedia and the engine of app state...

been running into several other posts that relate to this issue (see posts below)



one thing that is starting to sink in is that the hypermedia aspect relates closely media types.  in a nutshell, if replies from the server express media types and links, i should be able to figure out what kind of representation is allowed/expected at each link (end-point) along the way.  if a system (client) understands a collection of media-types, it stands to reason that the client can make GET to the server to retrieve a list of links and media types and then be able to compose a PUT/POST based on the media-type and pass it to one or more of the links.  i think i'm getting it...



An Opinion? Well, if you ask...: D'oh! REST already had contracts.

The contracts and protocol exist solely in the data. A client that understand a media type can then navigate the web of links based on knowledge gleaned from documents conforming to that media type. (This is exactly hypermedia as engine of application state).

Joe Gregorio | BitWorking | Do we need WADL?

Everybody's atwitter about WADL, a description file for REST services, and since it's supposed to be RESTful I regularly get questioned about it.

Shopping - SimpleWebServices

In the REST world, shopping revolves around application state - transitioning as required.

hypermedia as the engine of application state

i don't yet 'grok' the last one in the list:



REST is defined by four interface constraints:

- identification of resources

- manipulation of resources through representations

- self-descriptive messages

- hypermedia as the engine of application state





i'm learning, but i'm not quite there yet.

big leap forward today

i made a big leap forward in the rest-server framework today. i added support for using xml server-side templates that support x-include and other good stuff. that means it's possible to define an xml template that includes several calls to the /data/ portion of the system and then apply a transform to it on the server. it generates clean xhtml and sends it to the client (optionally caching it on the server, too).



all very sweet.



i ran into a few (not unexpected) hurdles along the way. first, since the /data/ part of the system is secured, templates calling into the /data/ area always failed rudely unless the user had already authenticated. i decided to implement a server-side system-user account that can access the data quietly as needed. this is the road of least-friction. i also plan on implementing a version that will force the user to log in first. that will take a bit of doing. i can easily write an x-include fallback, but i also need a clean way to pass credentials (i think) once the user has logged in. it's on my list of things to check out.



another stinger was the whole xml:base resolution deal. i decided to keep my xml templates in a folder not directly accessible to external users (prevents hacking). but that meant for each request, i needed to 'adjust' the internal path to point to the template pile. that - in turn - broke the xml:base for the x-includes. as a result, i now diddle the url as it comes in to make sure it matches the one for the intial template. now it all seems to work fine. this may not be the correct solution, but it works.



i also added suport for xhtml validating of user input on the server. i use the built-in validator for xml, but using a DTD/Schema instead. works great. now i can make sure saved data does not end up hosing the xml/xsl templates. i did run into a bit of trouble, tho. seems my escapeHTML javascript hack converts the input to HTML (not xhtml) each time i *read* it in. this is a bummer. i need to check into that since it means each time i edit an existing record, all my cool xhtml changes are removed.



finally, i did a bunch of code clean-up and some object renaming. i've been meaning to do that for quite a while, but just never took the time. now it's much cleaner (references to amundsen and REST are now gone) and i've moved a few things from local vars into const and such.



so, i have a solid templating solution started. i need to beat it up a bit before i will rest, tho [grin]. i figure building the public side of the weblog app will gfive me enough chance to expose weaknesses in the model.



onward and upward!

improved lis queries for the weblog app

i added a handful of improved list queries for the weblog app today. these include the following

/data/weblogs/?recent - returns the most recent five entries

/data/weblogs/?category={@id} - returns all the entries for the requested category id

/data/weblogs/?year={@yyyy}&month={@mm} - returns all the entries for the requested year & month



i also added some list filters for the website list:

/data/websites/?recent - returns the ten most recent website entries

/data/websites/?category={@id} - returns all the entries for the requested category id



this will make building a typical blog home page easier and more consistent.



i updated the handler code and had to twiddle the isapi rewriter regexp, too. the rewriter update we more tedious then the code update!  anyway, after making changes to the code and rewriter, the /data/* calls all work as expected. my next task will be to define the 'public' URI patterns and implement handlers for them, too.



i also need to confirm that the framework code is using the MVP XML library - specifically support for x:include. i like the x:include pattern since it makes it very easy to build server-side pages that contain several 'xml parts.' this also means that i need to make sure other things like state and security will work with x:include. based on my past experience, this should go fine, but i need to dig into it to be sure.



anyway, things continue to move along well. assuming all goes fine, it's quite possible that i'll have the blog ready for data entry by the end of this coming weekend.

added support for the website objects

i added support for the website objects today. this will be my 'blog roll.' for the blog.  that rounds out my initial set of objects for the blog:

- weblog

- category

- website



i tested them all against the data api and all work as expected. i think i need to update the _list function a bit. maybe return a default top X number unless the 'all' argument is passed, i think. i'll add some other filtered list requests later - by year/month, by category should be good starters.



i think i need to add the top X return to the website_list, too. i'll proly work that out this week.



then it's on to the 'live' version of the site. for starters i'll define the following:

- home page

  + last 5 full posts

  + list of categories

  + list of websites

  + link to get full list of posts (reverse chrono order)



later i'll add some other stuff like:

- contact page

- posts by category

- list of all websites (full blogroll)



i need to implement a url pattern for the posts that work on a 'hackable' model:

- /posts/yyyy/mm/post-id - returns a single post

- /posts/yyyy/mm/ - returns list of posts for that month

- /posts/yyyy/ - returns a list of posts for that year

- /posts/ - returns all posts



this probably will be handled via the rewriter

/blogging/yyyy/mm/

/blogging/?year=yyyy&month=mm



then i just need to implement the filters for the _list query.



i also need to get a good editor working for the blog posts.

- edit weblog entries (uses a category list)

- edit category entries

- edit website entries (uses a category list)



well - that's all for now.