[pgo]

So, I've been slowly learning all about the wonders of JavaScript and the DOM.

Now, I'm focusing my attention on Ajax (via Jeremy Keith's book "Bulletproof Ajax") because most Front-End Developer jobs I see advertised want some Ajax knowledge.

Let's talk about Ajax in general, its implementation, concepts, etc.

We'll start the conversation here:

I am, however, having a hard time conceptually with it. He mentions something about using the "open" method - as in, XMLHttpRequest.open("POST", "something.ext", true); - and how when you are sending data to the server it should always use POST and when you're retrieving data from the server, use GET. Fine.

Then I was thinking about my recent changes to spoetic.com, wherein I added a ratings system that uses GET to update a database. This seems like a grey area to me because GET can be used to send data as well. In the case of these ratings, it's sending the query string - ?action=rate&id=XX&rating=Y (rewritten to "/rate/XX/Y/" by mod_rewrite).

So, what's the deal? Should I be using POST even when GET works as in this example?

(Spoetic is not using Ajax right now. I may re-engineer it to be more modular so that I can once I figure this all out.)

[haku]

I'm pretty deep into the AJAX myself now, but am still fairly new to it. I think I grasp the concept fairly well though, as I've been writing all my own functions from scratch and implementing them into my company site.

I hadn't heard that about the using POST to enter data into the database (I assume you meant database and not server, as everything in AJAX is going to and from the server) and GET to get it out. The only times I have been using POST until now is when there is the potential for the information to be too long for a GET request (there is a limit to the number of characters that can be used in a GET request).

What I'm getting at is that I don't have the answer to your question! But I'm wondering about the theory behind J.K's comment. Is it a security thing? If so then I could potentially see the reasoning behind using post to enter data into the database, although if such is the case then it seems to me it would make better sense to get it out of the database with post as well. Does he elaborate anymore on the topic?

[seen.to]

Originally Posted by pgo

So, I've been slowly learning all about the wonders of JavaScript and the DOM.

Now, I'm focusing my attention on Ajax (via Jeremy Keith's book "Bulletproof Ajax")

Oooh thanks for the reminder bud. I was doing the same and bought the same book a couple of months ago then got busy and forgot I'd even bought it without so much as opening it. I'll be digging it out again real soon

[proc355]

post, get, put, & delete roughly correspond to the insert, select, update & delete in relation to sql databases

current/historic ua's don't implement put or delete so we're stuck with get & post—which is hunky dory since we can use post to effect put's & delete's by addressing different resources (have a noogle for REST (representational state transfer))

HTTP/1.1: Method Definitions

i'm frickin' knackered and off to my pit so sorry it's a bit short :P

[MikeMackay]

Great book, I bought it recently and have just finished reading it. I'm a big fan of the Hijax approach, especially if you read my comments on the 'Twitter' post back over in the General Forum.

With regards to using GET or POST, I think it's 50/50 and depends on the situation at hand. For something as simple/standard as a ratings system I don't think there would be any issue using GET to submit the values. As mentioned before, POST is more favourable when submitting large amounts of data and/or you need to 'hide' the data inside the request instead of them being sent attached openly to the query string.

Jeremy Keith is a big standardista so he will always take the route he deems right, but I don't think there is anything 'semantic' so to speak about your situation and whether using GET or POST really makes a difference, although JK might argue otherwise?

If you're happy with using GET then stick with it. I personally don't see any advantages to using POST here.

- Mike

[pgo]

I'm also digging the Hijax approach. It really fits in line with my general view of web standards as modularizing/separating the different tasks of web development - content, structure, presentation, behavior, and now server interaction.

Originally Posted by MikeMackay

Jeremy Keith is a big standardista so he will always take the route he deems right, but I don't think there is anything 'semantic' so to speak about your situation and whether using GET or POST really makes a difference, although JK might argue otherwise?

Agreed. Right after I posted that I read through Chapter 5 (Hijax) and his first example uses GET to request data from the server.

Maybe I'm just hung up on the words. I've been doing PHP for a while and never really thought about the difference much - I've always thought of it more as:

GET: transferring small amounts of info to the server, encoded in a URL.
POST: transferring larger amounts of info to the server, submitted from a form.

Really, either request is always sending something to the server. It just depends on how that data is sent to the server.

[haku]

This 'hijax' is a new word for me. Is that just keeping all your event listeners external rather than putting them inline?

If so, then I like it myself, I've been using that exclusively ever since I learned how to do it (which wasn't that long ago!)

[proc355]

URIs, Addressability, and the use of HTTP GET and POST

[MikeMackay]

Originally Posted by proc355

URIs, Addressability, and the use of HTTP GET and POST

Nice link, good reference for deciding on which method to use and why.

Haku: Yes, the principle behind 'Hijax' is to keep everything external and make use of 'progressive enhancement'. Allowing your application/site to function without the need for JavaScript first, then if JavaScript is enabled, you build a more fluid and sometimes better experience for the user.

- Mike

[haku]

Then I'm all about the hijax - I just didn't know the term. I've been building each of the sections on the current site I'm working on so that they function without javascript, then adding external javascript files overtop to add functionality. I love the separation of content, design and function!

God I'm a geek.

[MikeMackay]

Originally Posted by haku

God I'm a geek.

Welcome to the club!

- Mike

[.sleep]

i guess i need to buy this book then...

[Hunch]

I've been reading it recently out of curiosity, since I've heard it mentioned a lot in passing. The primer on javascript is as clear a basic reference as I've ever seen, and his ideas are pretty sound.

I think the JSON vs XML debate could have been touched upon a bit more, but he doesn't seem that keen on JSON for readability reasons (personally I'm in the pro-JSON camp) so maybe he skimped a bit on that area. Perhaps some simple database driven examples might have been a nice addition as well - I felt there were about 3 really solid chapters that would be beneficial to anyone new to AJAX, and the rest would be more useful for people who are relatively novice programmers who are new to just about everything.

The last chapter about the future of AJAX seemed a bit of an afterthought, and didn't really have anything useful in it.

Overall though, as a primer on the subject it did a pretty good job, and would recommend it for anyone who is new to AJAX, even if you're not that familiar with Javascript or the DOM. Experienced programmers might not get so much out of it.

[haku]

Thanks for the review - I may have to check it out, because that's about where I'm at.

[Hunch]

The one thing it does do well is show fairly clearly that AJAX is not nearly as difficult as people think. A lot of programmers seem to steer clear of it because they assume it's more tricky than it really is. In reality, you could pick up the fundamentals in less than an hour.