Namecoin API Server Interface Specification

[indolering]

No one has responded to my last post, which either means it was waaay to long or I said something disastrously stupid.

I should say right upfront that I don't understand Namecoin's internals that well, I know how it works in theory but I've never poked around with the implementation. I think this is why Domob and I disagree so heavily, he works on the internals so he sees a use for all of the stuff I think is superfluous.

I'm not entirely ashamed of my ignorance: 90% of usability engineering is about trying to get around your own expertise, to see things as a new user sees it. So I have a habit of taking notes on what I find confusing and my opinion tends to warp towards making those confusing things go away.

I think we should provide an entirely backwards compatible interface, one which mimics all of native function calls as closely as possible. We can do that elegantly by sticking to URL parameters on the bald API address: `api.namecoin.org?method=name&param=value`.

However, I also think we should come up with a better client API and I think we should start with the REST interface: `api.namecoin.org/d/name should` would the standard rest conventions.

I'm going to try to build both, while basing the latter on empirical research and trying to collect usability metrics. We'll see how close I come to achieving those goals, but I would like as much collaboration as possible.

: )

[sugarpuff]

No one has responded to my last post, which either means it was waaay to long or I said something disastrously stupid.

I still am planning on writing a reply to your post, but its length has meant that I've been putting it off while other urgent matters demand my attention.

That said, I'm following this thread and am happy to collaborate on the RESTful API specification, so I'm glad to hear that you'd also like to work together on this. If Namecoin needs anything, it's for people to get along and work together. Not always easy, and I know I'm sometimes responsible for that.

[indolering]

That said, I'm following this thread and am happy to collaborate on the RESTful API specification, so I'm glad to hear that you'd also like to work together on this. If Namecoin needs anything, it's for people to get along and work together. Not always easy, and I know I'm sometimes responsible for that.

Sug, I was planning on just scooping ALL of the data raw record data and then using map/reduce to transform it to the lighter-weight client API. I've been struggling to reconcile the different API's using CouchDB but it's just a square peg/round hold situation.

Since DNSChain is basically an RPC server, would you want to take on the "straight" API which mimics the raw format as closely as possible? Like I said, it wouldn't be as REST-like, more param/query based, and you would have to reintroduce some irritating bits (like the name actually being the full path and the TXID, etc) but it would be much more straightforward than multiple transforms on CouchDB.

[sugarpuff]

That said, I'm following this thread and am happy to collaborate on the RESTful API specification, so I'm glad to hear that you'd also like to work together on this. If Namecoin needs anything, it's for people to get along and work together. Not always easy, and I know I'm sometimes responsible for that.

Sug, I was planning on just scooping ALL of the data raw record data and then using map/reduce to transform it to the lighter-weight client API. I've been struggling to reconcile the different API's using CouchDB but it's just a square peg/round hold situation.

Since DNSChain is basically an RPC server, would you want to take on the "straight" API which mimics the raw format as closely as possible? Like I said, it wouldn't be as REST-like, more param/query based, and you would have to reintroduce some irritating bits (like the name actually being the full path and the TXID, etc) but it would be much more straightforward than multiple transforms on CouchDB.

This can be done, but file an issue on GH for it. The focus will be the RESTful API first, but a secondary, "raw" API can be implemented as well, it will just need some special care (whitelist of allowed commands, for example).