John Resig 26 Mar 06

Excellent, it looks very well designed. I can’t wait to play around with it.

Randy J. Hunt 26 Mar 06

Thank you, congrats, and all that goodness. This will be wonderful. Can’t wait to tie-in to our in-house stuff.

Kendall 27 Mar 06

Jason.
I’m very excited about this. I think that this will allow for basecamp to blossom into a product that is so useful in so many different ways.

Can’t wait to see what everyone does.

Curtis 27 Mar 06

I find it ironic that the BaseCamp API uses XML when David continually gripes about how much he dislikes XML over at his personal blog http://www.loudthinking.com/

Greg W. 27 Mar 06

————————————————————

I just finished listening to Jason�s SXSW talk and it was interesting to hear him repeat over-and-over that no one on the 37signals team has formal design experience.

So why is this interesting to me, because for many years, 37signals was providing design consulting work for a variety of firms. More information can still be found at the following link.

http://www.37signals.com/design.php

So essentially, 37signals was misrepresenting themselves to their clients as though they actually HAVE design expertise, but they don�t as Jason said in his SXSW talk.

Now, speed forward to the present day. Hopefully, 37signals is not again misrepresenting themselves in their products (Basecamp, Campfire etc) in knowing how to �properly� create a web-app. Since they claim to now have over 400,000 users (clients), hopefully they know how to do such things as: 1) Correctly secure your clients information (login, data etc..), 2) Have hot-site backup systems in place, 3) Be able to provide service level agreements, 4) Able to deal with the departure of a key employee (preventing one employee from knowing everyone).

I become concerned when I read posts about how people are worried how 37signals stores users passwords and other such posts.

I can only hope that they are not misrepresenting themselves again.

————————————————————

Mathew Patterson 27 Mar 06

37signals was misrepresenting themselves to their clients as though they actually HAVE design expertise, but they don�t

Greg, there is a big difference between formal design training and ‘design experience’. Plenty of successful people in different areas don’t have formal training in their area.

John 27 Mar 06

Greg W -

Design education != design expertise. Experience is a much bigger player - I’ve learnt more in my time since graduating from design school than in the entire 5 years I spent learning at two different art/design institutions. I don’t mean to be too damning of design education — I had a pretty great time, and did learn a lot — but the experience of working with real clients and actual deadlines and money cannot be replicated at a university or college.

I’m afraid your argument doesn’t hold much weight — that noone at 37signals has formal design education is entirely irrelevant.

Danno 27 Mar 06

What? No High REST?

Bah, someone’s gotta show us how to do it right.

Bryan 27 Mar 06

I find Greg W. comments thought provoking. He has a valid point that he makes.

I come from a Computer Science undergraduate background from a top univeristy (CMU) and have been a software developer now for 11 years.

What I constanstly find is people who try to start developing software, with no formal experience (e.g. schooling) … or even people who come from a business schools “info. system” backgrounds lack a huge fundamental understanding of software development.

For people who don’t come from a computer science background, you probably won’t understand that their exist some major fundamentals when it comes to developing software.

These fundamental are more difficult to learn in practice than in a classroom, getting at John’s comments, because software development is just different than most industries.

Based on Greg’s comments about security, backups, SLA - I wouldn’t be suprised if he comes from a computer science background and is trying to comment on such fundamental that are taught at universities.

Just my thoughts.

Bryan 27 Mar 06

Curtis -

I have yet to understand why DHH hasn’t figured out why technologies like Java, XML and the others that he constantly belittles have their place in the market. They are all good technologies, if used for what they are designed to address.

It’s as though he has never heard the common phrase, “use the right tool for the right job”.

Now yes, when he complains that Java is overkill for building a web-app like Basecamp he is probably correct. But then again, Java isn’t designed for building such small applications like Basecamp.

Chriztian Steinmeier 27 Mar 06

@Greg W: So basically you’re saying Jimi Hendrix couldn’t play the guitar? Or was he just not entitled to call himself a “guitar player”?

Lance C 27 Mar 06

Are you trying to make up reasons for why you think you formal education was valuable? :)

Morten 27 Mar 06

Bryan, common sense is not really something you learn in “How to backup 101” or “Securing FreeBSD 6.0 101” - is it?

Would it be fair to assume that people who host on FreeBSD, run an SSL offloader and develop excellent sysadm tools (Capistrano) are likely to know how to backup and grant secure access? Could we at least assume that, however unlikely it is, even if they don’t do it - that would be the result of a cost/benefit consideration?

Take a closer look at Rails, you may find the articles on scaling by hardware interesting (on the weblog).

JF 27 Mar 06

Let’s keep these comments on topic, ok? This post was about the Basecamp API, not about formal education or design training. If these off-topic comments continue we will remove them. Thank you.

Stephen Clay 27 Mar 06

Next up: TaDa and Backpack via JSON.. pretty please?

David Heinemeier Hansson 27 Mar 06

Addressing the one rant that relates to the API: Using XML.

I think XML is a very decent format for interoperable document exchange, which is exactly what we’re using it for here. Just like XML is a good fit for RSS and Atom.

I think XML is a HORRIBLE format for configuration, though. That’s where the term xml sit-ups come from.

Matt Lee 27 Mar 06

Jason,

Have you put any limiters in yet to prevent the service from getting hammered by someone’s bad code?

Timothy Appnel 27 Mar 06

The documentation does not specify which HTTP method (GET, POST, etc) are to be used (are accepted) with each API method. Some time ago it was noted on this weblog that using a GET with a URL that has side effects is dangerous and bad form. Has that changed and HTTP methods were not noted in the documentation or are we to assume all of these methods work with a GET?

David Heinemeier Hansson 27 Mar 06

Timothy, all queries are get, all updates are post.

Timothy Appnel 27 Mar 06

Ah, very good. Do deletes count as updates?

scott 27 Mar 06

yes, deletes count as updates.

GET is for getting data, nothing else. POST may be used for anything.

the specs explain in more detail.

Morten 27 Mar 06

good blog. great discussion

Ben Haldenby 27 Mar 06

Hurrah! Well done guys, can’t wait to see what the world builds. Anyone want to bet how long it will be before we see the first ‘Programming with Basecamp’ or ‘Using Basecamp API’ book published? And by that I mean a physical on-the-shelves book from a third party publisher.

RyanA 27 Mar 06

Cheers for this. I have clients that want to integrate some of their existing systems with BackPack :) I can’t wait to see what other people come up with, too!

RyanA 27 Mar 06

Gah, I mean basecamp!

Eelco 27 Mar 06

Why not XML-RPC or SOAP? Why, for heavens sake, introduce a proprietary protocol?

David Heinemeier Hansson 27 Mar 06

Eelco: Neither XML nor HTTP is proprietary. They’re actually must more established protocols than either XML-RPC or SOAP. Google on REST to read about others interested in just using XML and HTTP without the added complexity of envelopes on top.

Hubris Sonic 27 Mar 06

I agree, I would like to have XML-RPC, and/or SOAP too…

pocketSOAP? something…

regardless, NICE WORK. schweeet, this is turning out to be a great week…

Eelco 28 Mar 06

David: SOAP and XML-RPC are also build on top of HTTP and XML. I don’t think REST is comparable protocol-wise in this case.

I’m a big fan of lightweight protocols but I think that ‘envelopes’ are not just added weight, but also added value: the abstraction layer enables developers to make applications communicatie without worrying about the ‘language’ to do so (also ‘xml sit-ups’ imho).

Anyways, it’s nice to see more and more web applications releasing an API, so I should have started with a big congrats before bitching ;)

Randal "sw0rdfish" Santia 30 Mar 06

I hope this gets a response, so many days after the post.

I’m interested in doing something with the Time Logs of Basecamp, is there a reason why they aren’t accessible using the API? Is there any plan to implement access to them?

So far I like what I see, but access to the Time Logs is something I would love to have.

Cheers.
sw0rdfish