Parse Releases Their REST API(parse.com)
parse.com
Parse Releases Their REST API
https://www.parse.com/docs/rest
35 コメント
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 examples of a truly restful web service in practice? The only one I can think of offhand is Sun Cloud's API, which is pretty dead. Its hard to espouse the virtues of a truly restful API when there aren't any examples to point at.
Edit: The downvotes would seem to just further my point...
Why is it that there's no examples of a truly restful web service in practice? The only one I can think of offhand is Sun Cloud's API, which is pretty dead. Its hard to espouse the virtues of a truly restful API when there aren't any examples to point at.
Edit: The downvotes would seem to just further my point...
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.
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.
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 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/
http://guide.couchdb.org/
Subbu Allamaraju (ex-Yahoo, now eBay) has been the one proponent of REST that I believe speaks the most sense.
He understands that most "RESTful" APIs out there leave HATEOS as an afterthought, but he doesn't believe there is such a thing as a 100% RESTful API - you match the architectural style to the context of the problem you are trying to solve.
http://www.subbu.org/
He understands that most "RESTful" APIs out there leave HATEOS as an afterthought, but he doesn't believe there is such a thing as a 100% RESTful API - you match the architectural style to the context of the problem you are trying to solve.
http://www.subbu.org/
Saw Subbu speak at RestFest on Saturday. His talk seemed to promote REST as a set of constraints which produces a set of benefits. He argues that choosing a subset of constraints to achieve a subset of benefits is perfectly valid.
I would add that you must first have a deep understanding of the constraints and their associated benefits in order to make those types of informed decisions about your system's architecture. In my experience, the constraints are so orthogonal that a great number of the benefits of a system created using the REST architectural style only become evident in the overlap as the constraints empower each other.
Combining these constraints can elicit new benefits.
I would add that you must first have a deep understanding of the constraints and their associated benefits in order to make those types of informed decisions about your system's architecture. In my experience, the constraints are so orthogonal that a great number of the benefits of a system created using the REST architectural style only become evident in the overlap as the constraints empower each other.
Combining these constraints can elicit new benefits.
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/
[deleted]
“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.
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.
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.
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.
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.
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.
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.
In my experience, "correct" is often subjective.
[deleted]
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.
That's a valid criticism of APIs that think "it's not SOAP, so it must be REST", but this is close enough to REST that it seems pedantry to claim it isn't.
So all apologies to Roy Fielding, but through success, he has lost control of his terminology. This is what people mean by REST today.
So all apologies to Roy Fielding, but through success, he has lost control of his terminology. This is what people mean by REST today.
That reminds me of what happened to "Object Oriented". First, Alan Kay coined the term, having something like Smaltalk in head (emphasis on messages, and a strong dislike of unchecked side effects like setters and the assignment statement). Then the term was subverted, and we got C++ and Java (emphasis on classes, and a near-total disregard for the problems of pervasive side effects[1]).
My point is, we should be careful before we corrupt a term. Doing so corrupts our perception of the concept itself. And if it turns out the corrupt concept is less help than the pure one, too late : it's already popular.
[1]: That assignment thing really sucks: http://www.loup-vaillant.fr/articles/assignment
My point is, we should be careful before we corrupt a term. Doing so corrupts our perception of the concept itself. And if it turns out the corrupt concept is less help than the pure one, too late : it's already popular.
[1]: That assignment thing really sucks: http://www.loup-vaillant.fr/articles/assignment
Your argument appears to be unconcerned with truth, wisdom or understanding.
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.....
[deleted]
This looks simple and well-designed.
It's weird how so many APIs don't feel like they were actually designed by programmers. This one, on the other hand, just looks right.
It's weird how so many APIs don't feel like they were actually designed by programmers. This one, on the other hand, just looks right.
Awesome-- I was looking into Parse for a project I was working on, but was really needed access to their data storage otherwise I was going to have to have to hand roll it. Glad that I put it off a weekend! :)
I'm a big fan of these guys - i just send a support question and got a response in 4 minutes!
Yeah, these guys are great. I recently received a personalized email about an update they were releasing and then I was asked about the application I was building. It's little things like that that make me like these guys and will make me stick with them.
Edit: Spelling.
Edit: Spelling.
I've never heard of Parse before, so thanks for the link because it looks like a dream come true for me.
I'd like to see the ability to delegate the storage to other accounts. That is, I want XYZ app to use my parse account, not XYZs. It sounds a good place to hook in what I'd like to see around owning my own data and having universal access to it.
This service is pure magic awesome!
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...