www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Short forum post on REST API

reply Adam D. Ruppe <destructionator gmail.com> writes:
I just quickly wrote this up describing an idea I had earlier
today on combining rest api calls (example: foo(bar(10)) should be
just one call to the server) on a little forum I post to:

http://www.sveit.com/forum/viewtopic.php?f=11&t=3364

It's not really D specific, but I used D as my language to discuss
the idea, so I figured I'd share it here too. A lot of people I
talk to are surprised that I've been using D2 to write professional
websites and client apps alike for the last year, so I plan to write
more posts like this to explain how I'm doing things.

Like with this, a lot of the ideas are things that /could/ be done
in Javascript, PHP, etc., but it's never as elegant, or IMO as obvious,
to do as it is in D.
Apr 01 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:in63uu$b41$1 digitalmars.com...

I just quickly wrote this up describing an idea I had earlier
 today on combining rest api calls (example: foo(bar(10)) should be
 just one call to the server) on a little forum I post to:

 http://www.sveit.com/forum/viewtopic.php?f=11&t=3364

 It's not really D specific, but I used D as my language to discuss
 the idea, so I figured I'd share it here too. A lot of people I
 talk to are surprised that I've been using D2 to write professional
 websites and client apps alike for the last year, so I plan to write
 more posts like this to explain how I'm doing things.


Nice, common-sense-driven design strategy. Not enterprisey at all.  I like 
it :)  And it doesn't toss yet another layer on top the mess of 100 
poorly-designed layers that the (aptly named) web is already 
made^H^H^H^Hhacked together with.

A few minor typos:

ApiValue!int sueFunction(int a, int b); // <-- I doubt it's really a 
litigation function

umberToString  // <-- Funny, but probably not accurate

My only concern is how much can multiply-nested calls balloon the query 
string, and can that be an issue? And what about the feasability of 
something like this: foo(bar() + 2)


 Like with this, a lot of the ideas are things that /could/ be done
 in Javascript, PHP, etc., but it's never as elegant, or IMO as obvious,
 to do as it is in D.


The only way to make *anything* clean or elegant in JS or PHP is to not use 
them at all and say you did ;) Well, either that or a change in perspective 
via self-inflicted brain damage, but I prefer the former.
Apr 02 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:in6i74$16pd$1 digitalmars.com...

 "Adam D. Ruppe" <destructionator gmail.com> wrote in message 
 news:in63uu$b41$1 digitalmars.com...

I just quickly wrote this up describing an idea I had earlier
 today on combining rest api calls (example: foo(bar(10)) should be
 just one call to the server) on a little forum I post to:

 http://www.sveit.com/forum/viewtopic.php?f=11&t=3364

 It's not really D specific, but I used D as my language to discuss
 the idea, so I figured I'd share it here too. A lot of people I
 talk to are surprised that I've been using D2 to write professional
 websites and client apps alike for the last year, so I plan to write
 more posts like this to explain how I'm doing things.


 Nice, common-sense-driven design strategy. Not enterprisey at all.  I like 
 it :)  And it doesn't toss yet another layer on top the mess of 100 
 poorly-designed layers that the (aptly named) web is already 
 made^H^H^H^Hhacked together with.

 A few minor typos:

 ApiValue!int sueFunction(int a, int b); // <-- I doubt it's really a 
 litigation function

 umberToString  // <-- Funny, but probably not accurate

 My only concern is how much can multiply-nested calls balloon the query 
 string, and can that be an issue? And what about the feasability of 
 something like this: foo(bar() + 2)


 Like with this, a lot of the ideas are things that /could/ be done
 in Javascript, PHP, etc., but it's never as elegant, or IMO as obvious,
 to do as it is in D.


 The only way to make *anything* clean or elegant in JS or PHP is to not 
 use them at all and say you did ;) Well, either that or a change in 
 perspective via self-inflicted brain damage, but I prefer the former.


BTW, I love your signature line over there. :) I know IE gets flamed for not 
following the standards, and perhaps rightly so, but sometimes the 
IE-classic-way just makes the standards-way look like shit. Such as the way 
the mouse-buttons are handles in JS, or what the "width" and "height" 
attributes refer to.

I just had a quick look at YQL. I can't believe they chose SQL to base it 
off of. If you ask me, SQL is the COBOL/VB of the DB world, except it 
actually stuck.
Apr 02 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Nick Sabalausky wrote:

 I know IE gets flamed for not
 following the standards, and perhaps rightly so, but sometimes the
 IE-classic-way just makes the standards-way look like shit.


Yup. I always put some slightly inflammatory line in my signature
over there (and my avatar is usually ironic in some way).

I think the whole web standards thing is a pile of nonsense. Well,
it's good to have, but the attitude behind them, especially toward
IE, is just ridiculous.

Virtually everything "web 2.0" is built on was invented by IE -
hence the signature line. There's some new standards fixing
the old standard... by making it act like old IE. (box-sizing
in CSS is the big one.)

But, noooo, IE is evil.

If there's something IE started that they don't like, it's
OH NOES PROPRIETARY EVILNESS... but if Google does the same thing,
it's STILL IE's fault for not instantly cloning Google's
proprietary crap!

Unbelievable.

And, that brings me to something else. I hate the way the browsers
are so focused on poorly running DOOM in Javascript, but they
all ignore basic usability issues. Take one that got me recently:
file uploads don't give feedback.

How hard would it be for the browser to put in some kind of
progress bar over the form or something instead of just hanging
for a few minutes?

But noooo, we need WebGL.

Oh, I could rant about this all day, better not get too far
off topic again!



 If you ask me, SQL is the COBOL/VB of the DB world, except it
 actually stuck.


I don't know, it seems OK enough for the database, though it has
issues I hate (hence my recent database.d module). But reinventing
it is so weird.

Facebook did it too, but they at least had the good sense of
ditching their FQL for the most part in favor of the new graph
api, which is far more traditional in form.... and far easier
to use.
Apr 02 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:in7fuh$2rfu$1 digitalmars.com...

 Nick Sabalausky wrote:

 I know IE gets flamed for not
 following the standards, and perhaps rightly so, but sometimes the
 IE-classic-way just makes the standards-way look like shit.


 Yup. I always put some slightly inflammatory line in my signature
 over there (and my avatar is usually ironic in some way).

 I think the whole web standards thing is a pile of nonsense. Well,
 it's good to have, but the attitude behind them, especially toward
 IE, is just ridiculous.

 Virtually everything "web 2.0" is built on was invented by IE -
 hence the signature line. There's some new standards fixing
 the old standard... by making it act like old IE. (box-sizing
 in CSS is the big one.)

 But, noooo, IE is evil.

 If there's something IE started that they don't like, it's
 OH NOES PROPRIETARY EVILNESS... but if Google does the same thing,
 it's STILL IE's fault for not instantly cloning Google's
 proprietary crap!

 Unbelievable.

 And, that brings me to something else. I hate the way the browsers
 are so focused on poorly running DOOM in Javascript, but they
 all ignore basic usability issues. Take one that got me recently:
 file uploads don't give feedback.

 How hard would it be for the browser to put in some kind of
 progress bar over the form or something instead of just hanging
 for a few minutes?

 But noooo, we need WebGL.

 Oh, I could rant about this all day, better not get too far
 off topic again!


Cue sound bite of "Uh-huuh! You go, girl! (three finger snaps here)".

One of the things that gets me is the new video tag. The first time I heard 
about "this great new video tag" my reaction was "What they hell are they 
talking about? We've already has that since the 90's! It's called the object 
tag, and it works for more than video." Then later on when I needed to embed 
sound into a page (not my idea, I assure you) I discovered that the *cough* 
"good" browsers like Chrome don't support it. I had to embed the damn media 
into flash - something I'd sworn I'd never do.

About the file uploads: I bet they'd rather have it driven by JS and have a 
DHTML (or canvas tag) progress bar. And most likely driven by a Google API, 
of course. It would figure: Web people all for standards when it comes to 
protocols, no mater how bad the standard is, but when it comes to 
client-driven UI standards it's, "Hell no, we won't be having any of that!" 
Heck, when was the last time you saw a DHTML menu bar that actually behaved 
like menu bars on any real OS? The real ones dropdown on a click, always, 
never on a mouseover (and very thankfully so). Web apps make GTK apps seem 
like they're actually native (assuming a non-Gnome OS, of course).

And what makes all of this truly pathetic (as if it weren't already) is how 
it's all so blatantly trend-driven that it makes the fasion industry look 
almost down-to-Earth. God I hate the web.


 If you ask me, SQL is the COBOL/VB of the DB world, except it
 actually stuck.


 I don't know, it seems OK enough for the database, though it has
 issues I hate (hence my recent database.d module). But reinventing
 it is so weird.


Well, SQL is at least tolerable if you're just doing basic queries: SELECT, 
INSERT, UPDATE, no nested selects, no TSQL, etc. One you start getting into 
that other stuff, that's when it really gets irritating (so I avoid such 
things whenever I can get away with it, even if it is at the expense of a 
little speed - but everyone else is happily using PHP, so it's not like 
anyone even cares about speed on a web server anyway.)

Although even with those basic queries, SQL's psuedo-English syntax strikes 
me as uncomfortably COBOL/VB. And I never could shake the impression that 
INSERT and UPDATE were designed in isolation by two completely separate 
teams. Meh, at least it's statically-typed. These days, I should be happy 
just to have that.


 Facebook did it too, but they at least had the good sense of
 ditching their FQL for the most part in favor of the new graph
 api, which is far more traditional in form.... and far easier
 to use.


Yea, thank goodness for non-SQL DB APIs.
Apr 02 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:in7fuh$2rfu$1 digitalmars.com...

 But noooo, we need WebGL.


Heh, yup. Because after all, VRML just went over sooo well.
Apr 02 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Nick Sabalausky:

 Heh, yup. Because after all, VRML just went over sooo well.


Yeah... "what's old is new again" fits so well to web 2.0.

WebGL gets more minus points too since its on shaky technical
grounds too. It isn't very 'webby' if you will and may have
security implications... but wheee you can make shitty ports
of old games to the browser!
Apr 02 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 03.04.2011 00:22, schrieb Adam D. Ruppe:

 Nick Sabalausky:

 Heh, yup. Because after all, VRML just went over sooo well.


 
 Yeah... "what's old is new again" fits so well to web 2.0.
 
 WebGL gets more minus points too since its on shaky technical
 grounds too. It isn't very 'webby' if you will and may have
 security implications... but wheee you can make shitty ports
 of old games to the browser!


If it helps killing Flash I'm fine with WebGL, HTML5-videotag (I hope google's
WebM will win) etc. However that shouldn't be used in serious (non
demo/showcase) websites until proper support is ready in all major browsers.

As a web developer you should be glad that IE5/6's days are over and browsers
are a more standard-conformant - or did you like writing a different version  of
your websites for each browser?
A friend of mine who does web programming complained about having to work around
IE6's anomalies a lot until he could finally stop supporting it, so I'm kind of
surprised that you and Nick seem to like these old versions of the IE.

Cheers,
- Daniel
Apr 02 2011
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Daniel Gibson wrote:

 or did you like writing a different version  of
 your websites for each browser?


I've never found that to be actually necessary. Worst problems I
ever had as a developer were actually Firefox 2... while IE6 and 7
might have needed a few hacks, they could always do the job. Firefox
2 often left me hanging. I hated that piece of junk.

Anyway, with IE6 (IE5 is before my time), the worst that I ever needed
was a few isolated lines of javascript - which can be abstracted
into reusable functions - and a few little bits of CSS, easily
done with conditional comments.

It's really very little work, more like 10% more than the 100% more
implied by "different version [..] for each browser".

Hell, I think I spend more time writing

border-radius
-moz-border-radius
-webkit-border-radius

and similar -browser- prefixes over and over again than I spent
doing IE6 adjustments.


That said, I am happy to see it mostly gone, even if it's
replacements still suck in their own ways.


 surprised that you and Nick seem to like these old versions of the IE.


The real surprise is how much of HTML5 is just mimicing IE5's functions! It's a
good decision, just an ironic one.
Apr 02 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 03.04.2011 01:31, schrieb Adam D. Ruppe:

 Daniel Gibson wrote:

 or did you like writing a different version  of
 your websites for each browser?


 
 I've never found that to be actually necessary. Worst problems I
 ever had as a developer were actually Firefox 2... while IE6 and 7
 might have needed a few hacks, they could always do the job. Firefox
 2 often left me hanging. I hated that piece of junk.
 
 Anyway, with IE6 (IE5 is before my time), the worst that I ever needed
 was a few isolated lines of javascript - which can be abstracted
 into reusable functions - and a few little bits of CSS, easily
 done with conditional comments.
 
 It's really very little work, more like 10% more than the 100% more
 implied by "different version [..] for each browser".
 


Yeah, it may not be 100% - however I've heard from other people and read on the
web that supporting IE6 was really time intensive - more than 10%.
But it's just what I heard/read, I haven't got much experience with web
development myself.


 Hell, I think I spend more time writing
 
 border-radius
 -moz-border-radius
 -webkit-border-radius
 
 and similar -browser- prefixes over and over again than I spent
 doing IE6 adjustments.
 
 
 That said, I am happy to see it mostly gone, even if it's
 replacements still suck in their own ways.
 

 surprised that you and Nick seem to like these old versions of the IE.


 
 The real surprise is how much of HTML5 is just mimicing IE5's functions! It's a
 good decision, just an ironic one.


The functions may be great - as long as they're a standard and everybody
supports them.
But using functions that only work properly on a single browser sucks.
Apr 02 2011
parent "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:in8c2g$knb$3 digitalmars.com...

 Am 03.04.2011 01:31, schrieb Adam D. Ruppe:

 Daniel Gibson wrote:

 or did you like writing a different version  of
 your websites for each browser?


 I've never found that to be actually necessary. Worst problems I
 ever had as a developer were actually Firefox 2... while IE6 and 7
 might have needed a few hacks, they could always do the job. Firefox
 2 often left me hanging. I hated that piece of junk.

 Anyway, with IE6 (IE5 is before my time), the worst that I ever needed
 was a few isolated lines of javascript - which can be abstracted
 into reusable functions - and a few little bits of CSS, easily
 done with conditional comments.

 It's really very little work, more like 10% more than the 100% more
 implied by "different version [..] for each browser".


 Yeah, it may not be 100% - however I've heard from other people and read 
 on the
 web that supporting IE6 was really time intensive - more than 10%.
 But it's just what I heard/read, I haven't got much experience with web
 development myself.


My experience with IE6 (from back in the day) has been much like Adam's. 
Yea, sometimes something would be a little bit different on the two or three 
different browsers that were out there, but I never found it to be a real 
problem. I suspect that most of the big complaints about it were from people 
who didn't understand the medium enough to know that being pixel-perfect 
wasn't (isn't) appropriate.
Apr 02 2011
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:in889j$knb$1 digitalmars.com...

 Am 03.04.2011 00:22, schrieb Adam D. Ruppe:

 Nick Sabalausky:

 Heh, yup. Because after all, VRML just went over sooo well.


 Yeah... "what's old is new again" fits so well to web 2.0.

 WebGL gets more minus points too since its on shaky technical
 grounds too. It isn't very 'webby' if you will and may have
 security implications... but wheee you can make shitty ports
 of old games to the browser!


 If it helps killing Flash I'm fine with WebGL,


My immeditate reaction is to agree with you on that, because direct 
experience as both a flash-user and as a flash-developer has given me a 
strong personal hatred towards Flash. But, if WebGL is driven by in-browser 
JS (as I *think* it is, not that I've studied it closely), then I dunno, 
suddenly Flash doesn't sound quite so bad anymore. Heck, at the very least, 
Flash is already in byte-code when it's distributed, and the 
"JS-as-the-web's-asm" idea just gives me a rash. Plus it's cleaner/easier to 
block flash than to block specific JS features. Etc.


 [If it helps killing Flash I'm fine with] HTML5-videotag


I dunno. The thing that still bugs me about that is we *already* had the 
object tag, but then ever since YouTube came along everyone just stopped 
using it, Google outright left it out of Chrome, etc. It was just plain 
killed off in favor of flash. And now, ages later, they reinvent the object 
tag and try to convince me it'll finally pull web-A/V out of the flash 
shackes that *they* had placed web-A/V into in the first place? Even if I 
did feel that I could trust that claim (a shaky prospect), the fact remains 
that we *already* had a solution.


 (I hope google's WebM will win) etc.


Oh god yes. I suppose everyone knows I'm, well, not exactly a big Google 
fan, but the legal ball-and-chain that's welded to H.2[0-9][0-9] (whatever 
the hell it's called) just leaves it a complete non-option, IMO. I'd sooner 
use flv and an embedded player - and I've always hated the whole concept of 
flash video players.


 However that shouldn't be used in serious (non
 demo/showcase) websites until proper support is ready in all major 
 browsers.

 As a web developer you should be glad that IE5/6's days are over and 
 browsers
 are a more standard-conformant - or did you like writing a different 
 version  of
 your websites for each browser?
 A friend of mine who does web programming complained about having to work 
 around
 IE6's anomalies a lot until he could finally stop supporting it, so I'm 
 kind of
 surprised that you and Nick seem to like these old versions of the IE.


I don't really mean to say that I like the old IEs. It's just that:

1. They weren't nearly as bad as the Google/W3C fan brigade would have 
everyone believe.

2. They did a number of things that put the W3C-sanctioned equivalents to 
shame. (Things that are rarely acknoledged).

3. The "standards" are only now just starting to catch up in features, which 
kinda pulls the wind out of HTML5's sails. HTML5 isn't bad, it's just that 
it takes credit for things that it, 1. Stole from IE, and then 2. Changed in 
a non-backwards-comptible way (much like MS is often demonized for doing.)
Apr 02 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 03.04.2011 08:59, schrieb Nick Sabalausky:

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message 
 news:in889j$knb$1 digitalmars.com...

 Am 03.04.2011 00:22, schrieb Adam D. Ruppe:

 Nick Sabalausky:

 Heh, yup. Because after all, VRML just went over sooo well.


 Yeah... "what's old is new again" fits so well to web 2.0.

 WebGL gets more minus points too since its on shaky technical
 grounds too. It isn't very 'webby' if you will and may have
 security implications... but wheee you can make shitty ports
 of old games to the browser!


 If it helps killing Flash I'm fine with WebGL,


 
 My immeditate reaction is to agree with you on that, because direct 
 experience as both a flash-user and as a flash-developer has given me a 
 strong personal hatred towards Flash. But, if WebGL is driven by in-browser 
 JS (as I *think* it is, not that I've studied it closely), then I dunno, 
 suddenly Flash doesn't sound quite so bad anymore. Heck, at the very least, 
 Flash is already in byte-code when it's distributed, and the 
 "JS-as-the-web's-asm" idea just gives me a rash. Plus it's cleaner/easier to 
 block flash than to block specific JS features. Etc.


But Flash is a notorious security hole, sometimes crashes the browser, ...


 

 [If it helps killing Flash I'm fine with] HTML5-videotag


 
 I dunno. The thing that still bugs me about that is we *already* had the 
 object tag, 


The problem was that there were different codecs for videos (windows media, real
media, ...) and often websites prompted you to install their codec.. which
sometimes distributed malware etc.
It's better to have a video tag with a standard codec that is supplied by the
browser.


 but then ever since YouTube came along everyone just stopped 
 using it, Google outright left it out of Chrome, etc. It was just plain 
 killed off in favor of flash. And now, ages later, they reinvent the object 
 tag and try to convince me it'll finally pull web-A/V out of the flash 
 shackes that *they* had placed web-A/V into in the first place? Even if I 
 did feel that I could trust that claim (a shaky prospect), the fact remains 
 that we *already* had a solution.
 

 (I hope google's WebM will win) etc.


 
 Oh god yes. I suppose everyone knows I'm, well, not exactly a big Google 
 fan, but the legal ball-and-chain that's welded to H.2[0-9][0-9] (whatever 
 the hell it's called) just leaves it a complete non-option, IMO. I'd sooner 
 use flv and an embedded player - and I've always hated the whole concept of 
 flash video players.
 


Flash also supports H.264 and other patented MPEG crap.
Apr 03 2011
parent "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:inaa6r$27f3$1 digitalmars.com...

 Am 03.04.2011 08:59, schrieb Nick Sabalausky:

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message
 news:in889j$knb$1 digitalmars.com...

 If it helps killing Flash I'm fine with WebGL,


 My immeditate reaction is to agree with you on that, because direct
 experience as both a flash-user and as a flash-developer has given me a
 strong personal hatred towards Flash. But, if WebGL is driven by 
 in-browser
 JS (as I *think* it is, not that I've studied it closely), then I dunno,
 suddenly Flash doesn't sound quite so bad anymore. Heck, at the very 
 least,
 Flash is already in byte-code when it's distributed, and the
 "JS-as-the-web's-asm" idea just gives me a rash. Plus it's cleaner/easier 
 to
 block flash than to block specific JS features. Etc.


 But Flash is a notorious security hole, sometimes crashes the browser, ...


Yea, like I said, I do hate flash. It's just that pitting it against JS 
strikes me as the age-old "shit sandwich vs giant doucebag" debate. (/me 
tips hat to South Park)


 [If it helps killing Flash I'm fine with] HTML5-videotag


 I dunno. The thing that still bugs me about that is we *already* had the
 object tag,


 The problem was that there were different codecs for videos (windows 
 media, real
 media, ...) and often websites prompted you to install their codec.. which
 sometimes distributed malware etc.
 It's better to have a video tag with a standard codec that is supplied by 
 the
 browser.


The W3C could just as easily have said "use the object tag, use the X codec; 
any using-a-special-codec feature of the object tag is depricated".
Apr 03 2011
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
=46rom talking to our web programmers, each browser still has anomalies that=
 must be worked around. IE is no exception.=20

Sent from my iPhone

On Apr 2, 2011, at 3:30 PM, Daniel Gibson <metalcaedes gmail.com> wrote:


 Am 03.04.2011 00:22, schrieb Adam D. Ruppe:

 Nick Sabalausky:

 Heh, yup. Because after all, VRML just went over sooo well.


=20
 Yeah... "what's old is new again" fits so well to web 2.0.
=20
 WebGL gets more minus points too since its on shaky technical
 grounds too. It isn't very 'webby' if you will and may have
 security implications... but wheee you can make shitty ports
 of old games to the browser!


=20
 If it helps killing Flash I'm fine with WebGL, HTML5-videotag (I hope goog=


le's

 WebM will win) etc. However that shouldn't be used in serious (non
 demo/showcase) websites until proper support is ready in all major browser=


s.

=20
 As a web developer you should be glad that IE5/6's days are over and brows=


ers

 are a more standard-conformant - or did you like writing a different versi=


on  of

 your websites for each browser?
 A friend of mine who does web programming complained about having to work a=


round

 IE6's anomalies a lot until he could finally stop supporting it, so I'm ki=


nd of

 surprised that you and Nick seem to like these old versions of the IE.
=20
 Cheers,
 - Daniel
Apr 07 2011
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Nick Sabalausky wrote:

 A few minor typos:


Ah, the result of me being slightly lazy and changing the name of
the functions. First, I called it "someFunction", then changed
my name to the homophone "sumFunction" so it'd actually do something.

But, I did changes without proofreading afterward!



 My only concern is how much can multiply-nested calls balloon the
 query string, and can that be an issue?


I'm not sure; I just thought it up yesterday and haven't actually
used it yet.

But, I'm not too concerned. Odds are most calls would be simple;
I rarely want to do much mixing of web api calls anyway.

If it's too long for a query string, the same approach works
for POST values too - the body of a POST request is encoded the
same way as a query string, so same approach works there too.


 And what about the feasability of
 something like this: foo(bar() + 2)


I wouldn't want to build a whole language into the url, so this
would have to be offered as function. Then you simply do operator
overloading on the ApiValue struct to combine it, all lazily.

bar() -> ApiValue!int

ApiValue!int.opBinary!("+")(2) -> calls the server side sumFunction,
returning an new ApiValue, like seen in the original post.


And hah, I think D now is doing something Javascript just
can't do. We can hack through dynamic typing, but I don't think
the current version has op overloading at all.


 The only way to make *anything* clean or elegant in JS or PHP is
 to not use them at all and say you did


This is basically how I do them... that's one reason why I
was writing this. There's not really much need to access the
http apis I write through D - I can just "import mymodule;"
instead.

Exception: I write a client gui app a few weeks ago that worked
with the web server, so I used my api functions there. But, I
did it by diving into std.concurrency, so it needed a different
approach...

Now, I wonder if the get() function with callback could do it
in a different thread... probably not, the closure would be thread
local. But, passing it to some regular function pointer would
probably work.

Anyway, I'm digressing. Now though, there's some external PHP
components on external servers being added to the application,
so I've gotta make sure it's accessible from there easily enough
too.
Apr 02 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
I just implemented the concept described in that post in my web.d,
and earlier in the week, implemented automatic Javascript bindings
generation.

Here's a live demo:
http://arsdnet.net/apidemo.html

This is the server side implementation:
http://arsdnet.net/apidemo.d

Do not adjust your text editor - it's actually a mere 14 lines long.
You just write D functions.

Most the work is done in the helper modules
http://arsdnet.net/dcode/web.d

Depends on:
http://arsdnet.net/dcode/cgi.d
http://arsdnet.net/dcode/dom.d


(btw the struct members are all static due to a decision decision
I think I've changed my mind on, but haven't changed the code
yet. I think a class would be better though - can slash a lot of
the __traits(compiles) if I just use virtual functions.)

There's other features available in web.d not used here, like
automatic and hookable html form generation, output format
post processing, initialization functions, etc. You can also
accept a Cgi and ReflectionInfo object in the initializer if you
want to do more traditional web things or see what you have
in that struct.

(Originally, the idea was to autogenerate websites, so there's
a lot of code for datatype -> html, html templates, html forms,
etc. All that still works, of course:

http://arsdnet.net/cgi-bin/apidemo/foo

But I've been playing with program access recently, since I actually
prefer the traditional method of making the pages on the whole.
Since they can exist side by side in the same executable, it's
pretty awesome still.)


Anyway, FancyMain just calls three other functions, wrapped up
in a main:

    auto reflection = prepareReflection!(T)(cgi);
    run(cgi, reflection);

ReflectionInfo stores piles of info about your passed object.
All functions (and still to do: enums and structs) are checked
out. Their return type, name, and arguments - both names and types -
are stored. A template also generates a wrapper function that
makes the call from cgi info.

run() takes the cgi pathinfo and get/post data to call the wrapper.
It also catches exceptions to either handle automatically in the
case of html or wrap up for the other system in case of json.


run() also does a little piece of magic. If the path requested
is functions.js... it uses the reflection info to generate a
javascript object that mimics the D struct, along with some
other info:

http://arsdnet.net/cgi-bin/apidemo/functions.js

(See the bottom for the D function wrappers. There's quite a bit
of javascript there that I just wrote in web.d straight up.)

Note how the JS object name matches the D struct name too, and
the argument names match up.

also, if it's compiled in debug mode, the Javascript is made in
debug mode, giving better error messages, etc.


I might write an automatic PHP too, but php can actually call
the api functions without needing a code generator - it has
a feature similar to D's opDispatch. Using web.d's positional
argument support, it can just forward to the server without knowing
anything. (Some vendor's implementations of javascript have this
too, but you can't depend on it, so the codegen is better.)


There's a bunch of helper callbacks there too, to make using
the function return value easier in the async environment.

You can see that in apidemo.html - in the end, it does appendTo(),
which takes the returned string, treats it as html, and appends it
to the given element.

I'm planning on adding better typechecking there - if you return
a Html() or Element in D, it is html. If it's a string, it should
do append text instead. The static types are there - let's use them.




Anyway, enough blabbing. The interesting thing here is what all D
could do to make this work. When I get around to writing my
article, I'll discuss what it can do again, but also go into
how much of a pain it is to do this kind of thing in PHP and other
popular languages for both calling and implementing the web api.

D's built in documentation naturally helps here too. All the stuff
is generated from the same place, so it's easy to doc too.

I saw a php thing that tries to do the same, for example, but
you had to do things just write, had to manually register the
functions, and couldn't just write javascript normally... and, of
course, it's php. Ugh.
Apr 17 2011
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
Oh btw, the returned errors kick ass. Exceptions cross the
divide pretty well intact - it just works, and the messages
(in firefox at least) are pretty awesome. Try making errors too!
Apr 17 2011
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
Wow... actually, the names aren't always right, including in the
example.

I used a ParameterNamesOf!(), written by a newsgroup member a while
ago (I don't remember who), which cleverly uses typeof().stringof
and parses it to extract parameter names.

Strangely though, dmd seems to use the parameter names off the first
function of that type it sees.

Here, "int num" was first, so it used int num everywhere. If you
switch the second function "int wat" to the first position, dmd
gives that for both of them!


Of course, it works because the program uses the same method
to generate the code as to parse it. It's all consistent so it
works. My PHP based external caller uses positional parameters,
so it doesn't matter either. Only if you were to manually type
the argument names would you notice something fail.

But, I used the arg name for error messages and generated forms,
so it might be  noticeable there - it won't necessarily match up
with the documentation.

Blargh. But hey, it all works anyway! And if your signatures aren't
the same, the names work too. Even if they didn't work at all
though, this is still pretty win, especially if the D functions
return DOM elements!

Still to come: use D's reflection to give more behavior to pure
functions. Memoizing them (that is, using the HTTP cache
automatically) could give a huge benefit here.
Apr 17 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:iog3q7$2hn6$1 digitalmars.com...

I just implemented the concept described in that post in my web.d,
 and earlier in the week, implemented automatic Javascript bindings
 generation.

 Here's a live demo:
 http://arsdnet.net/apidemo.html

 This is the server side implementation:
 http://arsdnet.net/apidemo.d

 Do not adjust your text editor - it's actually a mere 14 lines long.
 You just write D functions.


Heh, sweet :) D's awesome.
Apr 26 2011