rjbs / rx
- Source
- Commits
- Network (1)
- Issues (0)
- Downloads (9)
- Wiki (1)
- Graphs
-
Branch:
master
rx /
| name | age | message | |
|---|---|---|---|
| |
.gitignore | Sun Aug 31 10:33:20 -0700 2008 | |
| |
LICENSE | Thu Nov 13 19:57:14 -0800 2008 | |
| |
README | Fri Dec 18 19:13:04 -0800 2009 | |
| |
js/ | Sat Aug 30 19:03:40 -0700 2008 | |
| |
perl/ | Mon Jan 11 19:42:57 -0800 2010 | |
| |
php/ | Wed Sep 03 20:24:34 -0700 2008 | |
| |
python/ | Sat Aug 30 19:03:40 -0700 2008 | |
| |
ruby/ | Tue Nov 11 05:50:42 -0800 2008 | |
| |
spec/ | Sat Aug 30 10:06:51 -0700 2008 | |
| |
todo.txt | Mon Sep 01 11:09:57 -0700 2008 | |
| |
util/ | Mon Jan 11 19:46:58 -0800 2010 | |
| |
www/ | Mon Jan 11 19:46:58 -0800 2010 |
README
What is Rx? When adding an API to your web service, you have to choose how to encode the data you send across the line. XML is one common choice for this, but it can grow arcane and cumbersome pretty quickly. Lots of webservice authors want to avoid thinking about XML, and instead choose formats that provide a few simple data types that correspond to common data structures in modern programming languages. In other words, JSON and YAML. Unfortunately, while these formats make it easy to pass around complex data structures, they lack a system for validation. XML has XML Schemas and RELAX NG, but these are complicated and sometimes confusing standards. They're not very portable to the kind of data structure provided by JSON, and if you wanted to avoid XML as a data encoding, writing more XML to validate the first XML is probably even less appealing. Rx is meant to provide a system for data validation that matches up with JSON-style data structures and is as easy to work with as JSON itself.
