Now without the delusions of grandeur!

I'm in the middle of an intense refactor of the Python implementation of  Its mainly based on experience I had using the Perl port at work (oh yeah, over the summer, I ported it to Perl so we could use it at work).

Since I've began this project, I've learned alot about REST and building APIs.  One of the main things I've discovered is that I'm not the only one working on this.  Not by a long shot.

Here are just a handful of other REST + JSON specification in the works:

The point is that this is a very popular problem.  And many people are excited to hack on it.  I expect the number of implementations and proposed specifications to continue to rise.

And so I'd like to hereby reduce my delusions of grandeur with regard to my first post about  I certainly think has some unique features and something to contribute to this area.  But I seriously doubt that it has any chance of becoming a widely excepted "standard" in the current environment.

What does that means for my future plans with regard to  Well, I'm going to focus more on the implementation than the spec. still has relatively little experience in the real world.  It would be good for it to learn its hard lessons before being committed to prose.  (Especially important when I am the author!  I'm notoriously slow at writting prose...)

With the number of REST + JSON specs and implementations continuing to grow for the foreseeable future, I think it would be better to focus on interoperability between them, rather than trying to choose one as the "true way" and sticking with it.  I think all the experimentation right now is a good thing!  Some really interesting stuff is coming out of it.

What we can do is work on making all these different REST + JSON protocols easier for the client to use.  Kris Zyp has put together an initial hyper-schema specification. A hyper schema could be made for each protocol (ie. one schema for Lingwo, another for Shoji, etc) which can be linked to a resource via an HTTP header. So a user agent could be written that can understand any REST + JSON resource that provides a hyper-schema.

This would allow all the service authors to keep experimenting. But the clients who wish to use these services could use one hyper-schema capable library to access them all.

Anyway, work on continues! I'll get some documentation up for it eventually. But I'm going to try and get the Lingwo Dictionary live before I even start that. More info on that soon...