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

Nobody Understands REST or HTTP

blog.steveklabnik.com

Post reply on HN
Print view View original

41–50 of 72 posts

Re: Nobody Understands REST or HTTP

#41

Post by javascriptlol »

javascriptlol wrote: post #38
javascriptlol wrote: post #36

Earlier quoted context omitted.

The problem is designing all this nonsense into the bottom layer in the first place. I've never heard a good argument as to why any of this is better than just starting with raw sockets for an app talking to a server. Take HATEOAS for example; a completely academic waste of time. Writing a tiny bit of API documentation isn't hard. Caching is an awful thing to be designing in without knowing the specific application.…

Don't downvote, comment. Or admit to yourself that you can't respond to my criticism.

Wow, what a weak crowd. No substantive criticism, just downvotes. The HN crowd should please refrain from arguing on the Internet about design until they've learned some basic systems programming.

Re: Nobody Understands REST or HTTP

#42

Post by drawkbox »

davedx wrote: post #35
drawkbox wrote: post #31

Earlier quoted context omitted.

I agree, lots of the Header only people live in a Utopian view of services. Many times these services are needed at the javascript, even plugin (flash, unity, etc) level that don't work well with hidden headers since all they have is a url and a body to make it work. The Academic view of REST is ideal but usage in the real world is difficulty with headers only. A situation that may arise is people not even aware they…

Can you elaborate on Unity not working well with headers? I've just started doing some web-stuff with it and found that so far it's been okay.

Services are a bit painful in Unity due to the WWW class: http://unity3d.com/support/documentation/ScriptReference/WWW...

You can use System.Net.* but if you want support across iOS, Android, Web, and Desktop you need to use WWW. Which does not allow you to read or set headers.

I have decent services working with it in JSON using LitJson but it is something they should work on and has prevented me from using headers much in Unity. Even the WWWForm class is weak but there are hidden methods to set and read headers, just they don't work on all platforms yet.

My biggest hiccup in making true REST has actually been in games where web standards and tools are still pretty fresh. So many C/C++/C#/Python/Lua etc proprietary web libs that to make things work you have to have some fallback to uri based states or resources. I typically implement that as a fallback i.e. the version 1 api with headers or url route to the same place.

Re: Nobody Understands REST or HTTP

#43

Post by javascriptlol »

javascriptlol wrote: post #41
javascriptlol wrote: post #38

Earlier quoted context omitted.

Don't downvote, comment. Or admit to yourself that you can't respond to my criticism.

Wow, what a weak crowd. No substantive criticism, just downvotes. The HN crowd should please refrain from arguing on the Internet about design until they've learned some basic systems programming.

Please downvote this comment too. The more you downvote me without commenting, the more you confirm my superior skills in system design.

Re: Nobody Understands REST or HTTP

#44

Post by DanielRibeiro »

walkon wrote: post #34
DanielRibeiro wrote: post #17

This was posted 7 months ago on HN (with 510 points!): http://news.ycombinator.com/item?id=2724488 Very lengthy discussion at that time.

I believe the author of this has refined/updated some of this thoughts since that first post.

I believe you are right. Also he is writting his own book: http://getsomere.st/ (linked from the part 2)

Re: Nobody Understands REST or HTTP

#45

Post by javascriptlol »

psadauskas wrote: post #39
javascriptlol wrote: post #36

Earlier quoted context omitted.

The problem is designing all this nonsense into the bottom layer in the first place. I've never heard a good argument as to why any of this is better than just starting with raw sockets for an app talking to a server. Take HATEOAS for example; a completely academic waste of time. Writing a tiny bit of API documentation isn't hard. Caching is an awful thing to be designing in without knowing the specific application.…

Except that when you follow all of REST, including HATEOAS, that part of the API documentation is FREE. And the caching is FREE, because its already been designed for you. Which is the whole point.

Still waiting for your answer.

Re: Nobody Understands REST or HTTP

#46

Post by lhnz »

hcarvalhoalves wrote: post #32

A lot of good points there, but the part about detecting mobile devices is a bit short sighted. Varying your content based on mobile User-Agent (or any User-Agent actually) renders public caches almost impossible to get right.

>> Varying your content based on mobile User-Agent (or any User-Agent actually) renders public caches almost impossible to get right.

Interesting. What would you recommend doing instead, supposing, for example, that you are meant to be returning a different set of items depending on a device identifier, and that you have to support 100s of devices? Should this be considered a different resource instead of a different representation?

Also, can you point me to a nice resource about public caches?

Thanks!

Re: Nobody Understands REST or HTTP

#47

Post by collint »

javascriptlol wrote: post #36
StavrosK wrote: post #2

This says versioning in the URI is wrong. Why? I much prefer separating my API versions into different files at the dispatcher level. Doing it with the header would be a mess in most frameworks, and I don't see what it hurts. Also, what about custom HTTP verbs? Many times I need something more than GET/PUT/POST/DELETE. What happens then? I haven't seen anyone talk about that.

The problem is designing all this nonsense into the bottom layer in the first place. I've never heard a good argument as to why any of this is better than just starting with raw sockets for an app talking to a server. Take HATEOAS for example; a completely academic waste of time. Writing a tiny bit of API documentation isn't hard. Caching is an awful thing to be designing in without knowing the specific application.…

How exactly do you expect build any automated tooling around your ecosystem of raw socket applications?

For example: indexing

You're going to need something that solves the problems HATEOAS solves when it comes to multi-service coordination.

Re: Nobody Understands REST or HTTP

#48

Post by javascriptlol »

collint wrote: post #47
javascriptlol wrote: post #36

Earlier quoted context omitted.

The problem is designing all this nonsense into the bottom layer in the first place. I've never heard a good argument as to why any of this is better than just starting with raw sockets for an app talking to a server. Take HATEOAS for example; a completely academic waste of time. Writing a tiny bit of API documentation isn't hard. Caching is an awful thing to be designing in without knowing the specific application.…

How exactly do you expect build any automated tooling around your ecosystem of raw socket applications? For example: indexing You're going to need something that solves the problems HATEOAS solves when it comes to multi-service coordination.

Who actually uses or needs this kind of tooling? What exatly is "multi-service coordination" and why should anyone non-academic building actual systems care what it means? HATEOAS doesn't solve the problem anyway. What happens when a field requires fixed-point arithmetic to two places? Your tools are going to get that wrong unless you start adding types. In the end you need humans to read proper documentation and implement carefully thought out solutions. This is the XML conceit all over again.

Re: Nobody Understands REST or HTTP

#49

Post by javascriptlol »

javascriptlol wrote: post #40
psadauskas wrote: post #39

Earlier quoted context omitted.

Except that when you follow all of REST, including HATEOAS, that part of the API documentation is FREE. And the caching is FREE, because its already been designed for you. Which is the whole point.

What? How can you say REST is going to give you a bunch of stuff "for free" when you haven't even seen the application. How do you know you're even going to get what you want? This is the central conceit here.

Again, downvotes but no comments. How embarrassing for HN that the crowd here can't justify their position.

Re: Nobody Understands REST or HTTP

#50

Post by telent »

javascriptlol wrote: post #40
psadauskas wrote: post #39

Earlier quoted context omitted.

Except that when you follow all of REST, including HATEOAS, that part of the API documentation is FREE. And the caching is FREE, because its already been designed for you. Which is the whole point.

What? How can you say REST is going to give you a bunch of stuff "for free" when you haven't even seen the application. How do you know you're even going to get what you want? This is the central conceit here.

How can you say (TCP|Unix|C) is going to give you a bunch of stuff "for free" when you haven't even seen the application. How do you know you're even going to get what you want?

You don't, of course, but it's usually a pretty reasonable assumption that the effort involved in implementing your own (reliable stream sockets|scheduler and memory manager|high level language compiler) will eclipse severalfold any advantage from doing so. If you don't find that the same obtains from using HTTP and hypermedia then that's your position and you're welcome to it, but don't go assuming your experience is universal.

Post reply on HN