RESTLog API

Timothy AppnelIf you havn't seen it, Joe's prototype and RESTful API can be found here.  A RESTful API for updating weblogs is a good idea. 

Overall, I'm positive on the notion of a Well Formed Web... though I would actually rather see a Valid Web.  The ability to automatically discover and generate dynamic or static proxies is a powerful notion.  One that need not necessarily require that all methods are POSTs or that actions be embedded inside the data.


I think the Well Formed Web is a necessary step on the way to a Valid Web. Experience with RSS should demonstrate that ;) Also, RSS shows that you can go very far without validity.

This does raise a question though; Valid with respect to what? Valid with respect to a DTD or a Schema or Relax NG or ...?

Can you elaborate what you mean by a proxy?


Posted by joe at

Well Formed is certainly a prereq for Validity. Until recently, there wasn't much awareness about the issues of RSS feeds which weren't even well formed, so I'm not sure you want to go there. ;-)

XSD certainly has the most momentum in the WS space, but any attempt to precisely document the format of a document is a step in the right direction.

Examples of proxy generators from WSDL and/or XSD: Python, VB, Java, and C#

Posted by Sam Ruby at

Oh, that kind of proxy. At this point I really can't see a way to create such a beast, which is one of the reasons I created WellFormedWeb.org, I want to create a range of RESTian interfaces for different services. The experience with real working examples should display some patterns, whether that leads to some manner of proxy generator remains to be seen.

Posted by joe at


More RESTful API Discussions.

Joe Gregorio and Sam Ruby have been busy discussing the use of SOAP and WSDL in RESTful APIs like Joe's RESTLog. ... [more]

Trackback from tima thinking outloud. at


A "valid web" is nice for nerds, because it lets us make decisions on technical grounds ("purchase order isn't valid instance of schema -> reject"), and lets us do cool stuff like serialize objects as XML via tools such as .NET has that hide the XML "cruft" behind nice clean abstractions. ON THE OTHER HAND, it begs an enormous number of human questions:

- How do those schemas get defined? Few who have ever been on a standards committee come away with a warm fuzzy feeling about the rationality of the process.

- What happens when they change, or vary across sub-sectors, or become obsoleted by changing realities? All that nerd-friendliness tends to be fragile in the case of change.

- Will the "suits" agree? My favorite example is the $1 Million purchase order that gets rejected for some nerdy XML reason, leading to, uhh, new employement opportunities in the Back Office. The "be liberal in what you accept" rule is much, much more PHB-friendly than validation.

Posted by Mike Champion at

Hi Mike!

FWIW, I agree with pretty much everything you said. Though I will note that you only have presented half of Postel's Robustness Priciple.

And I do have a number of thoughts published on what should happen when these things change. Expect More and Coping with Change, for example.

Posted by Sam Ruby at


Oh yes, the "be conservative in what you produce" half. Sure, schemas help on the production side because you can use them to couple the various bits of your production chain together, bind to procedural language tools, and make life easy for the nerds down your supply chain. Tightly coupled enterprises and tight coupling between the various tools that produce enterprise data makes a lot more sense than expecting your "customers" (literally or figuratively) to be tightly coupled to your datatypes.

I just think that the "be conservative" half as a Best Practice works a lot better in environments such as the HTML Web where the Right Thing was widely agreed on in principle, if seldom practiced. I agreed with most of the Coping with Change essay (thanks for the pointer). I guess I just come at this from a different perspective: assume chaos as the typical condition and be happy when you find structure that can be exploited. Starting from ASP.NET and friends seems to say "assume structure but be tolerant of a bit of chaos". In practice, I'm not sure that most of the actual code would be too much different.

I'm toying with the idea that schemas are not so much "contracts" between a producer and consumer of data but a "template" for what data would ideally look like from one or the other's perspective. Imperfect matches to the template can be dealt with to the extent that technology and domain knowledge allows. So, that lets one use strongly typed or databound tools to produce data according to one's own template, but doesn't assume anything but that the consumer can somehow map it onto a template that they recognize.

Posted by Mike Champion at

Toying with the idea? If so, you might like the first paragraph of the overview of this and the conclusion of this.

Posted by Sam Ruby at

Add your comment












Nav Bar