Live data from Hacker News

How Not to write a "REST" API

api.sharefile.com

111–117 of 117 posts

Re: How Not to write a "REST" API

#111
post #29

Earlier quoted context omitted.

Yes, I can see how they got where they did, too... When all you have is a hammer, everything looks like a nail...

Engineers like us can be such snots sometimes. If as a culture we want people to build great RESTful apis and a company attempts to do so, public shaming isn't the answer. But. Their homegrown text serialization format is pretty wack. They couldn't just use CSV?

That culture of being "snots" comes from engineers in the real world. The one where this kind of attention to detail means buildings fall on people.

I agree that maybe it's not necessary to carry over that cultural legacy to the internet, although so far it's worked pretty well.

If social pressure (public shaming) isn't the answer then what kind of pressure should be used? Public shaming is a pretty civilized way to enforce rules when you have no top down control that dictates those rules, I can't think of any alternatives that would be less harsh.

Re: How Not to write a "REST" API

#113

Earlier quoted context omitted.

But you can be 99.994% sure they're writing your plan text user name and password into their logs if you're using get, and if somebody breaks in and gets them, then they have your password, even if those passwords are properly hashed in the user database.

No, I wouldn't be 99.994% sure of that at all. In fact, I would assume that if they are suggesting that people use GET, that they are in fact not logging the query params, as any security audit would catch that. And again, if they are compromised, then they are compromised. It doesn't matter if they have logging disabled, someone who would have access to the logs also has access to either the httpd account or the roo…

Picking a comment at random to thank you for at least trying to explain to people why their assumption of what's being logged relates in no way to security.

At least one person appreciates someone taking the time to correct this rather serious misunderstanding.

Re: How Not to write a "REST" API

#114

Earlier quoted context omitted.

Engineers like us can be such snots sometimes. If as a culture we want people to build great RESTful apis and a company attempts to do so, public shaming isn't the answer. But. Their homegrown text serialization format is pretty wack. They couldn't just use CSV?

That culture of being "snots" comes from engineers in the real world. The one where this kind of attention to detail means buildings fall on people. I agree that maybe it's not necessary to carry over that cultural legacy to the internet, although so far it's worked pretty well. If social pressure (public shaming) isn't the answer then what kind of pressure should be used? Public shaming is a pretty civilized way to…

According to some the latest hn posts about facebook, in our industry you're doing something wrong if the building doesn't fall over from time to time ; ).

Public shaming can be a good idea, especially on people who are knowingly breaking the rules and holding back progress (See IE6).

However, I'm just glad people are creating APIs, especially because basically no one gets REST right anyways (Hint: if you can't click around your api in firefox with the JSONView extension, it's probably not RESTful).

Re: How Not to write a "REST" API

#116

Earlier quoted context omitted.

If you're learning about REST, do it right and make this book your bible - it's brilliant: http://www.amazon.com/Restful-Web-Services-Leonard-Richardso...

Correct link: http://www.amazon.com/Restful-Web-Services-Leonard-Richardso...

Whoops, sorry!

Re: How Not to write a "REST" API

#117

Earlier quoted context omitted.

If you're learning about REST, do it right and make this book your bible - it's brilliant: http://www.amazon.com/Restful-Web-Services-Leonard-Richardso...

Why should that particular book be the bible? I haven't read it, but I've flicked through it and seeing things like the suggestion that clients should "construct" URLs made me doubt its worth. Shouldn't Fielding's original thesis be the bible?

Ok, maybe bible was used to loosely. In my experience, I found it a well written, well balanced, useful primer for real-world development of RESTful web services that also has enough depth to make it a reference I've returned to since. That's better.
Post reply on HN