johns

You should probably reach out to them directly.

Buy their app and you can stream any episode whenever you want.

My podcast client fetches new episodes as they become available in the feed and then stores them for me to play whenever I like.

Your response is overly harsh. Consider there are political and financial challenges they might be dealing with as a non-profit that don't allow them to be as accommodating as you demand.

Can you post an example command to repro so I can look into it more closely? Thanks!

This really depends on the type of business behind the API. Transactional API models have worked really well (Expedia affiliates, payment gateways, messaging). It's really only been a problem for providers who didn't properly align their interests with the consumer of the API meaning one side of the equation was getting far more value than they were contributing. This tends to be most common in consumer service APIs.

I wrote a little bit about this here: http://thenextweb.com/dd/2013/03/12/apis-are-dead-long-live-...

Sign up?

You're not wrong. I said the same thing in the comments.

Flask + flask_restful

We love bugsnag. Been using the new dashboard in test for a few days and it's been great.

Interesting editorializing on the title...

A new site was just launched to help with this: apicommons.org

My general advice is if it's internal, build what feels right to your team. If it's external, research the APIs you like or are popular (Twilio, Stripe, etc.) and don't be clever.

If I can throw my own in: http://john-sheehan.com/blog/dont-build-the-best-rest-api-bu...

It's a lighter weight form of the same idea. SOA had a lot of great benefits for its time. This revision of those ideas also has a lot of merit.

Our public API is a front end for our other services with auth added on and better guarantees against breaking. We don't depend on it directly for anything public facing and I wouldn't suggest anyone completely rely the same API they offer partners/openly to avoid getting into a tough spot with managing changes.

If this is a strain on deployment and maintenance I would take a close look at those two processes in your organization. We maintain 18+ services (5 people) and having our front-end web apps call APIs only (never direct db calls) has not hit performance, deployment or maintenance issues. In fact, it's helped in all those cases, especially the last two (for us, YMMV yadda yadda).

The way we handle this (we have 18 internal services) is that processes requiring transactions are formalized into a endpoint/resource. The actual transaction becomes tangible (e.g. you can cancel them by DELETE-ing on the resource) instead of just being documented. Only logic the client needs is the data to kick off the process. Async or long-running processes get a little tricker, but polling or webhook callbacks work fine for us.

https://www.runscope.com (I'm a founder, happy to answer any questions.)

Hurl.it

Also check out Mashape.

I love this service. I've been beta testing it for a few weeks and Andrey has figured out just the right metrics to include in a very succinct manor. It's one of my favorite emails every week.

Previous discussions/submissions: https://www.hnsearch.com/search#request/submissions&q=vinays...

We write ours manually in markdown. I have yet to find a description format worth investing in that saves us enough time and is more expressive than that.

Why is there a length limit?

Great post, thanks for taking the time to write it up.

I'm curious how the discussions got started with Eventbrite. Were you discussing another kind of partnership first? How close were your existing contacts?

There are so many scenarios for debugging APIs that don't fall into the "I control both ends, so I should be able to see everything." camp. SDKs, poorly implemented or documented APIs controlled by a 3rd party (frequently even across a company where the people producing are far removed from the consumers), differing environments (works locally, not in staging, etc), UI-less machine-to-machine interactions (debugging webhooks is especially annoying) and many more.

If you check my bio, you'll see my bias toward these problems. But there are a lot more of them and a lot more variants than you give credit to.

We've (Runscope) tried to make debugging better than what you can do with a simple post catcher like requestb.in. The nice thing about our forwarding setup is that if a webhook fails on your server you have a log of that and can retry it.

It's not the only reason. PUT is the only way to do retryable creates since it's idempotent. Leaving it out is a huge omission.

Try flask-restful

You can send a webhook to localhost, just in a roundabout way using one of the local tunneling solutions: http://john-sheehan.com/blog/a-survey-of-the-localhost-proxy...

Great points though.

Some other options here: http://john-sheehan.com/blog/a-survey-of-the-localhost-proxy...

I personally think you should be using one that gives you permanent URLs (ngrok or Passageway) but that also keeps a log when you're client is disconnected. I'm pretty sure only our Passageway does that.

Are you a Racker now? Bio still mentions Loggly.

Congrats Simon and team! Great outcome for one of my favorite services. Can't wait to have you in SF.