It's a trivial example, but the point would be that the stdlib would have the ability to

a) Speak flutent HTTP b) Understand Content-Type c) Deserialize to a common format

all completely transparently. If the server returned XML or MsgPack, it wouldn't matter, the code would work the same.

Ideally, we could imagine this going a step further, and having the language speak REST entirely.

Python's requests is a nice prototype, ergonomically speaking, but we can go much further.

There is nothing currently built into Rebol stdlib that replicates exactly this. But here's an example of how it could be done...

    import <json>
    import <xml>

    load-*: function [site] [
        p: open site
        content: read p
        http: query p
        close p

        parse http/headers/Content-Type [
              "application/json" return (load-json content)
            | "application/xml"  return (load-xml content)
        ] else [
            fail "Content-Type not recognised"
        ]
    ]

    miserlou: load-* https://api.github.com/users/Miserlou
    print ["My name is" miserlou/name]

Is this hypothetical, or does the stdlib actually have load-json and load-xml?

Above works, the <json> & <xml> imports are pulled off this remotely hosted common library - https://github.com/r3n/renclib

You'll need the Ren/C branch of Rebol 3 for this:

* repo - https://github.com/metaeducation/ren-c

* pre-built binaries - http://metaeducation.s3.amazonaws.com/index.html

Okay, as someone who doesn't know REBOL, what is the effect of miserlou/name if the server returns XML? The string value of a top-level <name> tag?

Ah this was a different XML module than I was thinking of because this is complete DOM parser!! But even so it does produce (by default) a flat representation of the XML.

So, if for example, Github did return XML and it looked something like this (shown in Rebol console):

    >> x: load-xml {<root><name>Mr Miserlou</name><login>xxx</login></root>}
    == [
        <root> [
            <name> "Mr Miserlou"
            <login> "xxx"
        ]
    ]

So to get top-level tags it's just:

    >> second x                                                              
    == [
        <name> "Mr Miserlou"
        <login> "xxx"
    ]

Now load-json also has a flat option so that a good way to unify things. Here's an updated example showing this:

    import <json>
    import <xml>

    load-*: function [site] [
        p: open site
        content: read p
        http: query p
        close p

        data: parse http/headers/Content-Type [
              "application/json" return (load-json/flat content)
            | "application/xml"  return (second load-xml content)
        ] else [
            fail "Content-Type not recognised"
        ]

        ;; next 2 lines just turns it into a hashmap so can do:  miserlou/name
        ;; without it could have done:  miserlou/<name>
        ;;
        for-skip data 2 [data/1: to-word to-string data/1]
        make map! lock data
    ]

    miserlou: load-* https://api.github.com/users/Miserlou
    print miserlou/name

Okay, that's quite good! I'm going to see how good this can get with the Python std lib later. Probably not quite this nice.

Actually, I think I was wrong. You can get something this nice in Python. It just requires a bit more glue code in the case of JSON, and a lot more glue code in the case of XML. All told, I figure Python might 10x more code than REBOL here. I'm not sure if it's fair to hold this against Python though. It's "just" a question of libraries. And it's only fair to hold libraries against a language if the library itself would be hard to write. Which in this case I think it wouldn't.

Still neat though. Sometimes I wonder if I should learn REBOL (or Red?) or something.

Um, what if the server returned, say, a JPEG? Or a plain old HTML webpage, complete with inline CSS and script tags?