Live data from Hacker News

Parse Releases Their REST API

parse.com

11–20 of 36 posts

Re: Parse Releases Their REST API

#11
post #7

Earlier quoted context omitted.

Furthering our wanderings down this off-topic thread, I agree with you completely, but every time I point it out, I get accused of being a "pedant". I've implemented several truly restful APIs, and they've always worked beautifully, but they're internal or private. I tell others about it, and the immense advantages, but they see every other HTTP-RPC API out there and copy that instead. Why is it that there's no examp…

If you say you've written some very RESTful APIs internally, perhaps writing an article about the things you've specifically done from most APIs that makes yours RESTful and advantageous vs. a less RESTful API.

I do, periodically. The last one, though, was a couple years ago: https://news.ycombinator.com/item?id=713959

Be sure to read the first comment. I've sorta given up blogging about it, because I'm tired of fighting it. I am working on a side project, though, which exposes an actual Restful API, so maybe once I can use it as an example, I'll be able to blog more.

Re: Parse Releases Their REST API

#12

Earlier quoted context omitted.

“When I use a word,” Humpty Dumpty said, in rather a scornful tone, “it means just what I choose it to mean—neither more nor less.”

Are you saying Roy Fielding is like Humpty Dumpty? If so this doesn't appear to be a very useful or enlightening comment.

I'm saying if I wrote a "REST API" and everyone understood what that means, what would it matter whether or not it checks every box laid out by the originator of the term.

Re: Parse Releases Their REST API

#13

This is an HTTP API, not a REST API. http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...

Furthering our wanderings down this off-topic thread, I agree with you completely, but every time I point it out, I get accused of being a "pedant". I've implemented several truly restful APIs, and they've always worked beautifully, but they're internal or private. I tell others about it, and the immense advantages, but they see every other HTTP-RPC API out there and copy that instead. Why is it that there's no examp…

Twilio is pretty close.

Re: Parse Releases Their REST API

#14
post #13

Earlier quoted context omitted.

Furthering our wanderings down this off-topic thread, I agree with you completely, but every time I point it out, I get accused of being a "pedant". I've implemented several truly restful APIs, and they've always worked beautifully, but they're internal or private. I tell others about it, and the immense advantages, but they see every other HTTP-RPC API out there and copy that instead. Why is it that there's no examp…

Twilio is pretty close.

I hadn't looked at theirs before, but yeah, its a lot better than most. AFAICT, still doesn't have a single point of entry, but the response documents do have links to other resources, rather than IDs.

Re: Parse Releases Their REST API

#15

Earlier quoted context omitted.

Are you saying Roy Fielding is like Humpty Dumpty? If so this doesn't appear to be a very useful or enlightening comment.

I'm saying if I wrote a "REST API" and everyone understood what that means, what would it matter whether or not it checks every box laid out by the originator of the term.

That makes it an effective form of communication, but not correct.

If I talk to someone who's not computer-savvy and they describe a workflow as "I put the USB in the CPU and then drag all my files onto my screen" (verbatim quote) I can figure out what they mean and work with them, but they clearly don't understand the concepts.

Re: Parse Releases Their REST API

#17
post #13

Earlier quoted context omitted.

Twilio is pretty close.

I hadn't looked at theirs before, but yeah, its a lot better than most. AFAICT, still doesn't have a single point of entry, but the response documents do have links to other resources, rather than IDs.

Single point of entry: https://api.twilio.com/

Re: Parse Releases Their REST API

#18

Earlier quoted context omitted.

I'm saying if I wrote a "REST API" and everyone understood what that means, what would it matter whether or not it checks every box laid out by the originator of the term.

That makes it an effective form of communication, but not correct. If I talk to someone who's not computer-savvy and they describe a workflow as "I put the USB in the CPU and then drag all my files onto my screen" (verbatim quote) I can figure out what they mean and work with them, but they clearly don't understand the concepts.

In my experience, "correct" is often subjective.

Re: Parse Releases Their REST API

#20
post #9

Earlier quoted context omitted.

Furthering our wanderings down this off-topic thread, I agree with you completely, but every time I point it out, I get accused of being a "pedant". I've implemented several truly restful APIs, and they've always worked beautifully, but they're internal or private. I tell others about it, and the immense advantages, but they see every other HTTP-RPC API out there and copy that instead. Why is it that there's no examp…

I upvoted you. I would like to learn how to do REST "right", and (for me) it's easier to learn by playing with a working example that deals with "real world" issues as opposed to abstract snippets that only show how APIs get used. Any further insights/examples/pointers would be greatly appreciated.

I've been using CouchDB in a personal project for 6 months or so and it's been my first real exposure to an actual RESTful interface and I have to say that the experience has been pretty pleasant. I started working through the examples using curl in the CouchDB - The Definitive Guide and then moved on to building code to interface with it:

http://guide.couchdb.org/

Post reply on HN