Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Parse Releases Their REST API

parse.com

Post reply on HN
Print view View original

31–36 of 36 posts

Re: Parse Releases Their REST API

#31

Post by KevBurnsJr »

kevinpet wrote: post #23
generalk wrote: post #15

Earlier quoted context omitted.

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.

Your comment contradicts current linguistics. There is no "correct" separate from usefulness in communication. If someone wants to write a REST RFC, and people can talk about "RFC-6789 Compliant REST API" then correctness would reenter the picture.

"There is no "correct" separate from usefulness in communication."

I think you may have misunderstood your source. Subjective truth is only half of the equation. The other half is testing rational models against experience. If you understand the constraints of REST, you understand that it has implications not met by the API in question and thus claims to be something which it clearly is not.

Just because I tell you I'm a duck doesn't mean I'm a duck.

Re: Parse Releases Their REST API

#32

Post by mechanical_fish »

psadauskas wrote: post #11
generalk wrote: post #7

Earlier quoted context omitted.

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.

Thanks for writing that post. Very clear and informative.

Re: Parse Releases Their REST API

#34

Post by dm3 »

KevBurnsJr wrote: post #2

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

The following classification helped me resolve more than one REST terminology related conflict. Hope it'll be useful: http://www.nordsc.com/ext/classification_of_http_based_apis.....

Re: Parse Releases Their REST API

#35

Post by olefoo »

stanleydrew wrote: post #6
jethroalias97 wrote: post #3

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.

The reference is to Alice Through the Looking Glass by Lewis Carrol. It is a sad day when you can no longer expect an educated english speaker to have read the good Reverend's inspired nonsense.

Re: Parse Releases Their REST API

#36

Post by ap22213 »

KevBurnsJr wrote: post #31
kevinpet wrote: post #23

Earlier quoted context omitted.

Your comment contradicts current linguistics. There is no "correct" separate from usefulness in communication. If someone wants to write a REST RFC, and people can talk about "RFC-6789 Compliant REST API" then correctness would reenter the picture.

"There is no "correct" separate from usefulness in communication." I think you may have misunderstood your source. Subjective truth is only half of the equation. The other half is testing rational models against experience. If you understand the constraints of REST, you understand that it has implications not met by the API in question and thus claims to be something which it clearly is not. Just because I tell you I…

I think Roy Fielding and the other strict REST proponents need to do a better job of explaining why we laymen should follow the rules so closely. I have read a lot of Roy's work, and those of other proponents', and I still don't see a lot of value in staying so strictly to the 'word' of REST.

Much could be helped by 'the experts' just showing us rational laymen the cost-benefit analysis. Show me how things will fall apart over time, some data would be helpful. And let me see some case studies.

Currently, my non-REST "REST" interfaces seem to be working pretty well. And, when they don't work, I go and fix them. Seems easy enough, but obviously I'm naive.

Post reply on HN