I'd be willing to offer advice or a hand to a fellow HNer in need. This will require some discussion so e-mail me if you want to take me up on this offer.
Hey, I appreciate the offer to help. I ended up getting everything running on rackspace cloud, which was surprisingly easy considering I knew nothing about setting up a server.. so we'll see how this goes.
If I understand your comment correctly, I believe the API already works this way, except instead of using PUT, it uses POST for creating new records and zones. To create a record, a client would do a POST with the record to create in JSON as the request body.
Is there some reason to use PUT over POST in this case? By my understanding, POST is typically used to create new resources and PUT is used to updated existing resources.
Also, I can see now that the doc is pretty unclear on how the API expects data to be sent in a request's body. I'll be sure to fix that!
Thank you for your comment and yes I'm in need of more beta testers! Please e-mail me. My e-mail address can be found under my HN account.
Well yes technically the API does "work." The problem is that most people are coming from rails land (which is also where I'm from, btw) and over there, they have implemented "REST" as POST=create and PUT=update. This doesn't even really make sense in rails actually.
For a proper PUT request you have to specify the full body of the resource to be "put." It literally is supposed to be telling the server, "hey, put this thing I'm giving you at this url." For that to work you have to actually be delivering the thing, and in rails with PUT you are just submitting form data, which is a set of paramater name/value pairs (this is also what's going on with POST but in that case it's ok). This mistake derives mostly from the fact that rails works off of forms, and form data is always passed in parameter pairs, so you are never passing a full resource to the server. I'm still not sure why they don't just do create and update with POST though.
Anyway yes, your API will work fine. You can define it any way you want, and you don't even have to stick to the original intention of the HTTP verbs. It's just that to me, create should be idempotent in the case of creating zones and records, so why not use the idempotent http verb?
I thought there was something with trademark laws that meant owners had to actively protect their marks or risk losing the ability to pursue legal action against infringement. So even though SO and MO are buddy-buddy, couldn't allowing MO to use their name as is theoretically jeopardize SO's trademark?
There's nothing technical DNS-wise that would prevent the name 'canon' from resolving to an IP address, so http://canon could work. They could also add a MX record for the name 'canon' so @canon e-mail addresses would work too. Maybe ICANN has rules around gTLDs that would prevent this type of use?
I wish people would stop posting that. Yes, that covers most (though not all) of the RFC definitions of what constitutes an email address, but in practice you only want to accept a tiny subset of those.
Well, the really simple example is the string "postmaster". It is a perfectly legitimate email address, and almost always deliverable. But rarely something you want to actually accept.
With the up vote and down vote arrows, have one or the other light up when you mouse over a specific one, instead of having both light up. It will make it clearer which arrow you are about to click.
I like the layout of the two sided debates over the debates with more than two sides. The two sided debates have the sides and results right in the middle at the top of the page. On debates with more than two sides, having the sides and results off to the right makes them easy to miss at first. The first debate I looked at was a more than two sided debate and because of the layout, I was a bit confused on what the sides of the debate were. It seemed like the comments were the sides because of their placement and the up/down vote arrows.
Thanks for the input, I just made the quick css change. You're right about the multi-side layout, but I couldn't really think of any other way to do it. Actually, I think if I put all the sides above the arguments horizontally they would be easier to compare and more visible. I'll test something like that out.
