Thursday, March 15th, 2007

UED – URL Encoded Data

Category: JavaScript, Library, Remoting

<p>UED is a tiny library that takes a hash and converts it into a URL. Instead of passing a JSON string, for example, you could just construct a URL containing the transfer object. Update: I should mention that this is more about the format than the library…UED is a proposal for a standard way to encode an object into a URL, in the same way that JSON is more a format than a library.

Since it assumes you are making GET calls, RESTful design would suggest only using UED for non-destructive calls (i.e. calls that don’t change server state).

A hash is encoded like this:

javascript
< view plain text >
  1. //The JS Array format of the example given above
  2. var arr = {
  3.     'name':"Binny",
  4.     'year':2007,
  5.     'quote':"Hello, World!",
  6.     'os':['Windows','Linux','Mac'],
  7.     'software':{
  8.         'editor':"vi",
  9.         'audio':"xmms",
  10.         'video':"vlc"
  11.     }
  12. }
  13. var data = ued_encode(arr);

leading to a URL like this:

javascript
< view plain text >
  1. http://www.example.com/get_data.php?name=Binny&year=2007&
  2. quote=Hello%2C+World%21&os[]=Windows&os[]=Linux&os[]=Mac&
  3. software[editor]=vi&software[audio]=xmms&software[video]=vlc

However, there are no server-side decoders as yet.

Related Content:

Posted by Michael Mahemoff at 9:20 am
10 Comments

+++--
3.4 rating from 23 votes

10 Comments »

Comments feed TrackBack URI

That’s just a basic toQueryString-like function, right ?

Nice to have a library agnostic version around, though.

We seriously need some sort of standardization for this though, so that back-ends can pick it up more easily.

Comment by Tobie Langel — March 15, 2007

There is a limit on URL length (not sure what it is) so this technique is only good for small packets of data. Still a neat idea, especially if used in conjunction with the Image object.

Comment by Dean Edwards — March 15, 2007

Dean; it differs per browser and web server.

Comment by Maarten — March 15, 2007

I can tell of at least one server-side decoder out of hand.

It’s called PHP. PHP will natively parse such data into variables and arrays. And I’m pretty sure it was written with that in mind.

Comment by Nick — March 15, 2007

I haven’t taken a close look but it appears that format is the same format both PHP and Rails uses (I believe Rails borrowed the idea from PHP).

Comment by Eric Anderson — March 15, 2007

Using xin that would be something like this:
myadress.asp?setData(‘name’:”Binny”, ‘year’:2007, ‘quote’:”Hello,World!”,’os’:['Windows','Linux','Mac'],’software’:{ ‘editor’:”vi”,’audio’:”xmms”,’video’:”vlc”});

Comment by mikael bergkvist — March 15, 2007

@Dean: This encoding is also useful for the post body which doesn’t have a limit and is properly encoded by PHP into the $_POST variable.

@Eric: They are similar but Rails converts objects with numeric indexes into hashes whereas PHP makes them arrays. Also, some other languages seem to not like the [] to declare arrays.. For regular hashes though they pretty much all work the same.

I recently wrote a Prototype version of this same thing that was designed primarily with PHP in mind since other languages seem to have more limited decoding schemes. It supports any combination of nested arrays and hashes when used with PHP and nested hashes at least with all other languages AFAIK. An important difference between ued_encode and mine is I use Prototype’s Hash methods rather than for.. in loops which is a necessity if you are using Prototype-extended hashes but creates a problem if you use keys named after any of prototype’s Enumerable methods (each, findAll, collect, etc..)
Test page: http://colin.mollenhour.com/posttest.php
Code: http://pastie.caboo.se/47059

Given the major differences in server-side languages’ decoding behavior I think that any complex data structures are better encoded as JSON rather than a query string.

Comment by Colin — March 16, 2007

The URL can take 2k of data… which is a pretty large sized request. But it can get even more simpler than this… just take the JSON string and escape it into the URL. Let a server side parser just get the entire querystring, decode it and parse it with a JSON library… then the rest of the processing can happen.

You end up with pretty nasty URL’s, but it handles a pretty sizable amount of data, and you can’t get any easier (no special libraries needed). The URL’s look like thus….

http://127.0.0.1:8080/something?%7BparamOne%3A%22something%22%2CparamTwo%3A%7Bid%3A12%2Cgood%3Afalse%2Cstring%3A%22something%20more%22%7D%7D

…which isn’t uber pretty, but the client and the server side are *very* happy to play with it.

Comment by Arron Bates — March 16, 2007

This string is perfect for parse_str php function (and He calls a php page :D) but this kind of query string has different problems:
1 – it’s not standard (not implemented on every other program languages)
2 – it’s more redundant than JSON (how many times You need to write array name? arr[]= … arr[] … now think on big arrays or objects)
3 – it doesn’t preseve native variable type, in your example the year 2007 will be recieved as a string, as boolean, float, int, null and other values …

So, do we really need this “new” JSON alternative?

Comment by Andrea Giammarchi — March 16, 2007

can anyone tell me how to get the value in the URL using javascript?
like $_GET in php and Request.QueryString in ASP.

Thanks alot.

Comment by zoiz — March 23, 2007

Leave a comment

You must be logged in to post a comment.