greptilian logo

IRC log for #rest, 2015-10-29

#rest on freenode has been logged here from May 2014 until end of July 2018 but logging has been suspended because the channel has been riddled with spam since August 2018 with no end in site. See the following blog posts about the problem:

Until the spam problem has been dealt with and logging can resume, please visit our wiki at https://trygvis.io/rest-wiki/

Thanks.

| Channels | #rest index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary

All times shown according to UTC.

Time S Nick Message
01:44 fuzzyhorns joined #rest
02:47 cvander joined #rest
02:57 baweaver joined #rest
04:51 ralphschindler joined #rest
04:51 fuzzyhorns joined #rest
05:05 jatb joined #rest
06:03 cvander joined #rest
06:18 fuzzyhorns joined #rest
07:50 fuzzyhorns joined #rest
09:04 chthon joined #rest
09:20 fuzzyhorns joined #rest
09:23 _ollie joined #rest
09:58 graste joined #rest
10:12 rosstuck joined #rest
10:49 fuzzyhorns joined #rest
12:06 wsiqueir joined #rest
12:19 fuzzyhorns joined #rest
13:06 _ollie joined #rest
13:12 ironChicken joined #rest
13:30 Macaveli joined #rest
13:48 fuzzyhorns joined #rest
14:08 mezod joined #rest
14:25 bluezone joined #rest
14:52 ralphschindler joined #rest
14:58 mezod joined #rest
15:08 simonv3 joined #rest
15:15 fuzzyhorns joined #rest
16:02 ralphschindler joined #rest
16:39 fuzzyhorns joined #rest
17:30 tojani joined #rest
17:33 Macaveli joined #rest
18:04 fuzzyhorns joined #rest
18:19 ralphschindler joined #rest
18:48 wavded joined #rest
19:26 fuzzyhorns joined #rest
19:27 blahdeblah joined #rest
19:50 Macaveli joined #rest
19:53 wsiqueir joined #rest
20:02 Macaveli joined #rest
20:31 wsiqueir joined #rest
20:38 benzrf joined #rest
20:38 benzrf hello
20:39 benzrf im loosely familiar with the big ideas of REST
20:39 benzrf i was wondering what using HATEOAS would mean in practice
20:40 benzrf it seems to me that if you're writing an actual API for use in, i.e., programming applications, API consumers are going to be making some assumptions about what kind of data is present in a response
20:41 benzrf so if your application is already accounting for the fact that the result of GETting a user contains a list of comments, and is going to be displaying buttons to go to each comment, how does HATEOAS factor in?
20:42 benzrf how can the response tell the app what the user can do next, when the app is already making assumptions about that by virtue of not being a completely generic 'rest api client'?
20:47 fuzzyhorns joined #rest
20:47 Coldblackice joined #rest
20:49 whartung benzrf: the point of HATEOAS is to delegate the assumptions to server, and away from the client.
20:49 whartung All of those assumptions made by the client are potential points of failure when those change underneath its feat
20:49 whartung *feet
20:51 benzrf whartung: what kind of assumptions does it delegate?
20:51 benzrf i guess what i'm failing to see is
20:51 benzrf which assumptions are delegatable that arent already covered by normal api design
20:51 benzrf could you explain?
20:52 whartung here's a contrvied example.
20:52 whartung You need to go to the county clerk to get a birth certificate
20:52 whartung so you drive down to the county office, and in the front lobby is directory. It says "Birth Certificates, Suite 300"
20:53 benzrf yeah, but that kind of thing is sort of
20:53 whartung so you go to Suite 300, they give you a form and you fill it out. it says pay $25. You turn in the form and $25 and get a birth certitiface
20:53 whartung so.
20:53 whartung now, a year later, you need another one.
20:53 whartung since you kept a copy of the form, you drive down to the county seat, form filled out, with $25 in hand
20:53 whartung YOu go to suite 300
20:53 benzrf nvm, listening
20:54 whartung well, suite 300 is "House renovation Permits" now, the Birth Certificates section has moved.
20:54 whartung So you hunt that down, go there, give them the form and $25
20:54 whartung but the form has changed. and the price went up.
20:55 whartung all of those are assumptions that we as developers make every day about "how things work"
20:55 benzrf yeah
20:55 whartung if you went to the driectory when you arrived at the office, you would have gone straight to Suite 400, where it says the new location is
20:55 whartung If you read the new form, you would have filled it out properly and seen you need $35 now.
20:55 benzrf so...
20:56 benzrf you're still hardcoding the assumptions of "first go to the birth cert office, then fill out the form, then pay"
20:56 benzrf you're just offloading the literal values?
20:56 whartung "They worked before, so why not"
20:56 sfisque basically what whartung is saying in a more crunchy way, is hateoas gives us a "mechanism" for providing introspection of our api's so clients can adapt at runtime
20:56 benzrf i mean, if you use HATEOAS
20:56 whartung correct
20:56 benzrf kk
20:57 whartung in HATEOAS, you'll hit the root resource, and it will give you the new rel for the action you want to perform (if the aciton even still exists).
20:57 benzrf i think what confused me was the distinction between hardcoding the assumptions i just mentioned and hardcoding their parameters too
20:57 whartung If you use a templae or form system, the application will tell you what fields that it's interested in.
20:58 whartung so, in the Perfect World, your client "knows" how to interpret the different rels presented by the application, and how to navigate them, and how to properly fill in the information it requests.
20:58 whartung and you code doesn't make those assumpitions.
20:59 whartung Now, if the app adds a new rel that you don't understand? well, that's the breaks. Ideally that's new functionality that your client is not missing
20:59 whartung that's a versioning issue.
20:59 whartung But, all that said, writing such clients is Really Hard
20:59 whartung so 99.9999999% of folks don't do it.
20:59 whartung "Screw it, I'm posting this JSON -- if it breaks, they can call me and I can fix it"
21:00 benzrf so in an extremely exaggerated REST design, the API is essentially a regular website but without display info, and the client is just user interface?
21:00 benzrf and REST more generally as an actual practice is kind of trying to approach that as far as is actually useful?
21:01 whartung that depends on your application and requirements.
21:01 benzrf kk
21:01 sfisque as with any philosophy, it is our plight to build a mansion, and live next door in a hut
21:01 whartung the reason "the web" works mostly well is that the "client" is this carbon based lifeform that can intuit what to put in to the little boxes.
21:01 whartung conmputers are notoriously BAD at intuition
21:02 benzrf yeah
21:02 benzrf thats basically what was confusing me
21:02 fumanchu_ so are developers ;)
21:02 whartung but, for example, do you know what the URL is to see your shopping cart on Amazon? I know I don't, but I can do that any day of the week. I just "know" to click on the "shopping cart" button.
21:02 benzrf since hateoas seemed geared toward trying to recreate that mode of interaction
21:02 whartung that "shopping cart" button is a "rel" as we call it.
21:03 whartung A program can "look" for a rel in the payload to "know" where eto go next
21:03 whartung this lets the application dictate workflow to client
21:03 benzrf whartung: but the rel name would need to be hardcoded wouldnt it
21:03 benzrf (not a contradiction, just a qualifying question)
21:04 whartung of course. But it's "hard coded" on the amazon website too. IF they had a picture of a flower, odds are good I wouldn't be able to find the shopping cart, now would I?
21:05 whartung so, that's what the documentation does. It tells you as an implemenator what the rels are, and what their requirements are
21:06 whartung I talk about it here: http://stackoverflow.com/questions/20335967/how-useful-important-is-rest-hateoas-maturity-level-3/20336307#20336307
21:09 benzrf kk
21:12 benzrf whartung: is "You don't need it, your app isn't big enough, and it's not long lived enough to matter." supposed to be making fun of that decision, or is it actual advice
21:12 benzrf i'd assume latter, but. not sure
21:12 whartung no, it's just the truth of the matter.
21:12 whartung we have entire IT departments built around making sure brittle RPC systems work
21:13 whartung because the investment to make the systems more robust is quite high. "Robustness" is a "non-functional requiremnt". Given the question of whether someone wants perceived robustness vs that new report, guess which one they'll ask for first.
21:14 benzrf well
21:15 whartung And repeat that every week until 5 years later, the system has still not been made robust in any universal way. Rather, over time, you've discovered the particularl wear points where "well, yea, lets make THIS PART a bit more robust so the phone stops ringing", and those fixes are made.
21:15 benzrf the answer you wrote and what you're saying now are coming across to me as derisive of the mentalities that make 'brittle rpc' more practical & implying that a world where ppl took the time to make everything RESTful would be better
21:15 whartung The thing is, the people simply do not have the time to go the robust path. We're not writing software for the space shuttle.
21:16 whartung we are "ok" with systems that await chaos every day.
21:16 whartung We are CULTURALLY obligated to embrace chaos.
21:16 benzrf ok hold on
21:16 benzrf what im asking is
21:17 benzrf are you actually saying that rest is not necessary in many cases, and would not be in an ideal world either, or are you saying that ideally everything would be restful, but in practice that doesn't work because of imperfections in the world & culture?
21:17 benzrf because im not sure which to parse
21:18 whartung It's not necessary in many cases, in fact most cases. REST has costs outside of simply development complexity - it's not really the most efficient system either (the more flexible and durable a system gets, the more complex and slow it gets)
21:19 benzrf kk
21:19 whartung A credit card company handling 100's of millions of transcations a day, not really appropriate to use a self describing text based payload, for example
21:20 benzrf its just that every time you say that it seems contextually kind of backhanded, like "oh its not necessary, doing things ACTUALLY WELL is too hard a lot of the time"
21:20 benzrf alright tyvm for explaining things
21:20 benzrf later, possibly!
21:20 whartung well, if it was easy then there's no real excuse to not do it, right? For example, I get to leverage the reliabiity of TCP because it's "easy" rather than doing my own checksums etc.
21:20 whartung I don't use UDP for a reason
21:21 benzrf left #rest
21:21 whartung scared another one off...
21:21 whartung "Don't let that door sla….never mind"
21:21 sfisque lolz
21:22 fumanchu_ the architectural epiphany is that what "done well" means is always a delineation of tradeoffs in nonfunctional requirements
21:22 whartung I like that, I'm going to stick with that UDP analogy for a biut...
21:22 whartung right
21:54 pdurbin whartung is so crunchy
21:54 * whartung grabs a handful of pretzels and carrots
22:06 timg___ joined #rest
22:06 whartung was my analogy no good?
22:06 sfisque i think he was referring to my paraphrase
22:09 fuzzyhorns joined #rest
22:26 pdurbin whartung: good analogy. sfisque is the one who called you crunchy :)
22:27 * whartung looks knowlingly at the celery
22:27 sfisque actually, i was referring to my explanation.  i guessi could have said that clearer
22:28 sfisque aka, my paraphrase was the crunchy version of what whartung was analogizing
22:45 fuzzyhorns joined #rest
22:55 pdurbin ah
23:24 simonv3 joined #rest

| Channels | #rest index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary

#rest on freenode has been logged here from May 2014 until end of July 2018 but logging has been suspended because the channel has been riddled with spam since August 2018 with no end in site. See the following blog posts about the problem:

Until the spam problem has been dealt with and logging can resume, please visit our wiki at https://trygvis.io/rest-wiki/

Thanks.