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.

started my weblog implementation

finally got the courage to start to implement my weblog in the new REST framework <ta-da!>.



i was able to implement the database side (weblog, category, websites) in a little more than an hour. of course, i'd done some planning ahead of time so the implementation was just 1-2-3 simple. that included the table definitions as well as the standard sprocs that produce xml output from sql server (_list, _read, _add, _update, _delete).  later, i suspect i need to add some customized _list sprocs (most recent, search by date, etc.).



i was able to build each http handler in about 30 minutes. this involved copying an existing handler and modifying a few references to XSD and XSL files. then actually creating the XSD to validate the input and XSL to convert the XML input into acceptable T-SQL to submit to the database server. i got the weblog and category classes completed. i still need to implement the website class, tho.



also, i set up an endpoint for the weblog and the category classes. that meant updating my handlerfactory class and modifying the auth-url and auth-users xml files to control access to the new endpoints.  that took just a few minutes.



finally, i copied my stock html-ajax page that allows me to target the endpoint and do add/update/delete actions. this is my basic test bed. that took me less than 30 minutes to handle both the weblog and teh category. i was able to create sample data for both classes - no problem.



i also took the time to re-org the endpoints. now, all the actual data access is done through the /data/* URI. originally, i had the data behind each app (/running/runlogs, eating/foodlogs, etc.), but as the data library grows, i think it will be easier to control (esp. access control) if it all appears under a single /data/ endpoint (/data/foodlogs/, data/runlogs/, etc.). i'm not sure how deep to make the hierarchy - there's no limits, i guess. it will take time and some experimenting, but i'll get it.



i need to implement the website endpoint (handler and test page), but that should take less than 30 minutes. once that is done, i'll be ready to implement a 'live' display and edit service for the weblog.  i'm thinking that i will finally start to integrate the DOM/DHTML UI components that i scouted over the last few months (tabs, tables, tree, etc.).



anyway, it's been a good week. doing this next app has a bit more complexity and it's giving me a chance to expand the features and value of the rest framework. all fun stuff!