| 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 |
