| Time |
S |
Nick |
Message |
| 00:36 |
|
|
fuzzyhorns joined #rest |
| 01:16 |
|
|
huckleberry78 joined #rest |
| 02:53 |
|
|
fuzzyhorns joined #rest |
| 03:09 |
|
|
fuzzyhorns joined #rest |
| 03:16 |
|
|
fuzzyhorns joined #rest |
| 03:17 |
|
|
huckleberry78 joined #rest |
| 04:10 |
|
|
linux_dr joined #rest |
| 04:14 |
|
|
linux_dr joined #rest |
| 04:15 |
|
linux_dr |
Hi... |
| 04:15 |
|
linux_dr |
Does anyone here have experience with HAL? |
| 04:16 |
|
linux_dr |
How do you address HATEOAS in your REST protocols? |
| 04:18 |
|
linux_dr |
As I understand it, HATEOAS is a REST requirement. |
| 04:21 |
|
linux_dr |
Does anyone know what I'm talking about? |
| 04:23 |
|
linux_dr |
Sounds like I'm talking to myself. :-( |
| 04:37 |
|
sfisque |
linux_dr patience. post your questions, and if someone pops in, they will respond. most of us idle for hours/days at a time |
| 04:39 |
|
linux_dr |
The general question is how do you, collectively, as REST API designers, address the HATEOAS requirement in your APIs? |
| 04:42 |
|
sfisque |
design. it always goes back to design |
| 04:43 |
|
sfisque |
another important thing is to tease apart which parts |
| 04:43 |
|
sfisque |
"need" to be RESTful versus those that don't/shouldn't be RESTful. |
| 04:44 |
|
sfisque |
trying to force an entire application to be RESTful is a fool errand, but that does not invalidate the importance of REST. you have to treat it as "another tool in the toolbox" rather than "IT SOLVES EVERYTHING… PWN!!!" |
| 04:47 |
|
sfisque |
a good example of this was at a previous gig i had. they had designed a password management workflow that spanned several API calls (which can be fine) but they ignored the fact that such a setup requires an XA tolerant setup (you need rollback capability at each endpoint) so that if you stitch them together, you can roll back previous successes if the sequence fails at any stage point. we got into this heated discussion on how X |
| 04:50 |
|
sfisque |
you have to design appropriately, which goes both ways. build the app to fit REST, but judge whether REST is the proper model for the app before you write the whole thing |
| 04:53 |
|
linux_dr |
sfisque: a valid point... But given that he |
| 04:53 |
|
linux_dr |
That this is a REST channel, assuming you're implementing a REST API, how do you support HATEOAS? |
| 04:55 |
|
sfisque |
how? many ways. leverage existing libraries. write your own. the REST "manifesto" is pretty generic and can be solved by leveraging many different technologies (servlets, portlets, php pages, etc.) |
| 04:56 |
|
linux_dr |
Anyone? Anyone? Buller?... Lol |
| 04:57 |
|
sfisque |
i would say, start with your existing infrastructure and go from there (are you restricted to apache httpd? tomcat? nginx? jboss?) since that will dictate what your available techs are to leverage/use |
| 05:00 |
|
linux_dr |
sfisque: I don't see how that addresses the issue. |
| 05:02 |
|
sfisque |
your question is very vague. the simple answer is, choose a mech (leverage a framework or write your own), and implement the principals laid out in fielding's paper. if you ask a more concrete question, the people in this channel can give you more concrete answers. |
| 05:07 |
|
|
bigbluehat joined #rest |
| 05:07 |
|
linux_dr |
sfisque: HATEOAS as I understand it, is reasonably specific: whenever you respond with a resource, that response must include URIs of related resources that it would make sense to traverse from the given resource. |
| 05:09 |
|
linux_dr |
HAL is the only mechanism that I'm aware of to standardize representation of these related resources. |
| 05:13 |
|
linux_dr |
Not that I expect something like that to be standardized... But it can help |
| 05:13 |
|
sfisque |
aye, but you're describing the "what". your question was "how" |
| 05:13 |
|
sfisque |
and the how is, " you design it" |
| 05:15 |
|
sfisque |
a decent off the cuff analogy i can think of is this: rest and hateoas are like how you HAVE to have a int main() in your C program, but what that method does and how you fragment the program is dependent on your design. |
| 05:19 |
|
linux_dr |
I think you misunderstand the question... Let's say I have a resource called .../users/1234 . In this application you want to provide a HATEOAS link to .../users/1234/orders ...the semantics for this URI should be apparent from the REST response, or the URI isn't very meaningful. How do you make the ../users/1234/orders semantics apparent in the response? |
| 05:19 |
|
|
FreezingDroid joined #rest |
| 05:20 |
|
sfisque |
now that's a concrete question, other than, what do you mean by semantics? are you meaning, how does the client app infer what that link produces? |
| 05:22 |
|
sfisque |
are you trying to design for client "auto discovery" of linkage? |
| 05:22 |
|
linux_dr |
How do you represent what http verbs the endpoint accepts. If you want to POST to create an order, how do you convey what parameters are recognized, which are required, are there type restrictions, etc? |
| 05:22 |
|
sfisque |
if so, that's beyond my knowledge and someone else can pipe in |
| 05:22 |
|
sfisque |
i would say, that's backwards |
| 05:22 |
|
linux_dr |
How so? |
| 05:23 |
|
sfisque |
assume a client will attempt any verb at any endpoint and produces meaningful responses for cases that are unsupported |
| 05:23 |
|
sfisque |
which from a security standpoint is better because you are coding defensively rather than assuming the client is always going to be sane and do what you want |
| 05:25 |
|
linux_dr |
I agree you need to handle all verbs appropriately... But there is value in knowing which are useful before you send them. From an interface standpoint if for no other reason. |
| 05:25 |
|
linux_dr |
I certainly don't want to send a POST to determine if POST is valid. |
| 05:26 |
|
linux_dr |
Back in a few mins. |
| 05:26 |
|
sfisque |
i dont know if there is a standard way to communicate that, BUT someone else can always chime in and correct me |
| 05:40 |
|
|
rickharrison joined #rest |
| 05:42 |
|
|
locks joined #rest |
| 05:43 |
|
|
wsiqueir joined #rest |
| 05:45 |
|
|
linux_dr joined #rest |
| 05:46 |
|
linux_dr |
sfisque: like I said HAL is SUPPOSED to be a way to specify that, but i'm not sure if it's rich enough for all of that. |
| 05:47 |
|
|
angular_mike_ joined #rest |
| 05:47 |
|
|
ramsey joined #rest |
| 05:47 |
|
linux_dr |
I was hoping some of the HAL folks might be on this channel, but it appears not anyone awake at the moment. |
| 05:50 |
|
sfisque |
aye |
| 05:53 |
|
|
bigbluehat joined #rest |
| 05:53 |
|
linux_dr |
Was wondering specifically if this spec may offer a good supplement to HAL : https://github.com/cyril/opushon |
| 05:57 |
|
sfisque |
interesting but i dislike the forced reliance on json. it would be nice to see something like this implemented in a way where the client can request the representation format (json, xml, yaml, etc.) |
| 05:59 |
|
linux_dr |
No argument here... There is some discussion on the HAL list of why providing the http verbs in the response is unnecessary, but I'm not sure I'm following the logic. |
| 06:02 |
|
linux_dr |
HAL has been spec' for JSON and XML, but there has been some disinterest in the XML side of it |
| 06:04 |
|
|
_ollie joined #rest |
| 07:19 |
|
|
huckleberry78 joined #rest |
| 07:32 |
|
|
graste joined #rest |
| 07:36 |
|
|
ramsey joined #rest |
| 07:37 |
|
|
rickharrison joined #rest |
| 07:38 |
|
|
ChrisAnn joined #rest |
| 07:41 |
|
|
locks joined #rest |
| 07:53 |
|
|
bigbluehat joined #rest |
| 07:53 |
|
|
ekroon joined #rest |
| 08:07 |
|
|
angular_mike_ joined #rest |
| 08:11 |
|
|
FreezingDroid joined #rest |
| 08:26 |
|
|
rosstuck joined #rest |
| 09:08 |
|
|
quimrstorres joined #rest |
| 09:20 |
|
|
huckleberry78 joined #rest |
| 10:47 |
|
|
quimrstorres joined #rest |
| 11:16 |
|
trygvis |
morning |
| 11:21 |
|
|
huckleberry78 joined #rest |
| 11:28 |
|
|
quimrstorres joined #rest |
| 13:13 |
|
|
quimrstorres joined #rest |
| 14:06 |
|
|
saml joined #rest |
| 14:45 |
|
|
philbot joined #rest |
| 14:45 |
|
|
Topic for #rest is now #rest REpresentational State Transfer | logs: http://irclog.greptilian.com/rest/today | http://tech.groups.yahoo.com/group/rest-discuss | http://code.google.com/p/implementing-rest/ | http://en.wikipedia.org/wiki/Representational_State_Transfer |
| 15:04 |
|
|
DrCode joined #rest |
| 15:06 |
|
|
wsiqueir joined #rest |
| 15:09 |
|
|
foist joined #rest |
| 15:17 |
|
|
fumanchu_ joined #rest |
| 15:46 |
|
|
baweaver joined #rest |
| 18:09 |
|
|
FreezingDroid joined #rest |
| 18:24 |
|
|
quimrstorres joined #rest |
| 19:23 |
|
* bigbluehat |
remains baffled that JavaScript has no access to the initial page's HTTP request.... |
| 19:23 |
|
bigbluehat |
by initial, I mean the response headers |
| 19:33 |
|
|
ModusPwnens joined #rest |
| 19:37 |
|
trygvis |
boo |
| 19:57 |
|
whartung |
meh, it's too late by then. The page is but a wrapper and runtime environment. Seems to me a modern web page is little more than a single empty DIV tag and several MB of JS to fill it in. |
| 20:05 |
|
fumanchu_ |
perhaps precisely to get access to the response headers via xhr ;) |
| 20:06 |
|
trygvis |
whartung: 2.08MB of JS on average! |
| 20:07 |
|
whartung |
:) |
| 20:09 |
|
|
_ollie joined #rest |
| 20:09 |
|
whartung |
As a general rule, I don't like web apps. I find them routinely awful. The modern ones even more so. The combination of all the dynamic elements combined with notifying 87 different tracking companies makes "the web" in general a mostly terrible place. |
| 20:10 |
|
fumanchu_ |
amen |
| 20:10 |
|
trygvis |
well, the alternative is also quite horrible |
| 20:10 |
|
* fumanchu_ |
was just berating his team for calling the same endpoint 18 times with no-cache for one view |
| 20:11 |
|
trygvis |
but the tracking part is very bad |
| 20:11 |
|
whartung |
I just switched to Apple Mail over the GMail client. While the Apple Mail app certainly has issues, so far it's just be…niiiiice….over gmail. |
| 20:11 |
|
whartung |
yea, I hear ya trygvis |
| 20:11 |
|
whartung |
right now, every website on the planet is spamming my phone to "download the app". As if I want one app per bookmark…thanks a lot. |
| 20:11 |
|
trygvis |
I wouldn't mind a installed app if it would be as easy to write as html apps |
| 20:12 |
|
fumanchu_ |
as soon as Apple buys Google it might be |
| 20:12 |
|
trygvis |
well, chrome kinda already has it with |
| 20:12 |
|
whartung |
UI is hard. Period. All of the toolkits suck :). Every. Single. One. |
| 20:13 |
|
whartung |
but I will say |
| 20:13 |
|
whartung |
Back In The Day(™) |
| 20:13 |
|
trygvis |
yes, but with the html(5) ones they contain less code to write an as sucky interface at least |
| 20:13 |
|
whartung |
my most productive period was doing "green screen" 80x24 apps with simple screens and Fkeys and modal popups. |
| 20:13 |
|
whartung |
Ugly, but man was it fast and easy to get stuff out. |
| 20:14 |
|
trygvis |
whartung: you old man, you'll love this: http://www.coboloncogs.org/ |
| 20:14 |
|
whartung |
hah |
| 20:14 |
|
whartung |
yea |
| 20:15 |
|
whartung |
Hey, I wrote an entire distribution system - -alone using that stuff. Screens, reports, processes, interfaces, the whole blinking kit. order entry, credit/debit memos, inventory, traffic (shipping), updated it every year as marketing wanted Brand New PRICING!! \o/ etc. etc. |
| 20:16 |
|
whartung |
good times getting pre-printed forms to line up on the blankety-blank printers.... |
| 20:17 |
|
whartung |
and the accounting interface of course (GL, AR, AP…naturally…gotta pay for this stuff...) |
| 20:17 |
|
* fumanchu_ |
can't bring himself to say the P word |
| 20:18 |
|
whartung |
I hope it's not "payroll"... |
| 20:18 |
|
* whartung |
won't touch payroll |
| 20:18 |
|
fumanchu_ |
those things that add ink to paper |
| 20:19 |
|
whartung |
oh |
| 20:19 |
|
whartung |
:) |
| 20:19 |
|
whartung |
funniest thing |
| 20:19 |
|
whartung |
one of the scariest jobs I did |
| 20:19 |
|
whartung |
was at a magazing company |
| 20:19 |
|
whartung |
they cancelled a magazine |
| 20:19 |
|
whartung |
and had to refund a gazillion subscribers. |
| 20:20 |
|
whartung |
so we had to do a process and print job to print all of the checks. |
| 20:20 |
|
whartung |
hoo boy |
| 20:20 |
|
whartung |
Check printing is the High point of excitment in AP lol |
| 20:20 |
|
fumanchu_ |
beats labels |
| 20:20 |
|
whartung |
oh no, labels are nothing |
| 20:21 |
|
whartung |
"Oops..job failed -- we have to void 2000 checks..." |
| 20:21 |
|
fumanchu_ |
heh |
| 20:21 |
|
whartung |
labels are blank, checks have those nasty numbers in teh corners you ahve to keep track of. |
| 20:21 |
|
whartung |
and with accounting, not a lot of "undo" |
| 20:21 |
|
fumanchu_ |
see? I've blocked that all out |
| 20:22 |
|
whartung |
just credits and all that... |
| 20:22 |
|
whartung |
good times |
| 20:22 |
|
fumanchu_ |
Printer Toner Stress Disorder |
| 20:22 |
|
whartung |
haha |
| 20:22 |
|
whartung |
I have a printer story for you :) lol |
| 20:23 |
|
whartung |
we had a remote sales site, only at christmas |
| 20:23 |
|
whartung |
so one year, we simply had them call in on a terminal. Easy, but 12 hrs of long distance phone calls (that dates me) left it unpopular |
| 20:24 |
|
whartung |
next year we set up a linux box, that folks would log in to and it would PPP in to our machine. Still long distance, but now sevearl users and a printer and online lookup. |
| 20:24 |
|
whartung |
We simply set the printer up as a remote printer under lpd…stock in trade linux stuff. |
| 20:25 |
|
whartung |
year after, they decided to use a local "internat" provider, and dial locally, routing our traffic over the innawebs |
| 20:25 |
|
whartung |
but |
| 20:25 |
|
whartung |
the yahoos blocked the LPD ports... |
| 20:25 |
|
whartung |
"fine" |
| 20:26 |
|
whartung |
what I did was set up a inetd job on PORT 25(!!), and had a script on the host end that would just open that port up and shove the print file down. the Inetd job basically cat'd whatever came trhough port 25 to the printer. |
| 20:27 |
|
whartung |
so, in theory, if someone tryied to SMTP to our IP they'd have been talking to our printer lol |
| 20:27 |
|
whartung |
"The internet sees censorship as damage and routes around it...: |
| 20:27 |
|
fumanchu_ |
security, too, it would seem |
| 20:28 |
|
trygvis |
whartung: nice |
| 20:28 |
|
whartung |
security is over rated... |
| 20:29 |
|
trygvis |
at the uni we used LPD to queue songs to play, lp artist/album/*.mp3 and a printer that played the jobs |
| 20:29 |
|
whartung |
hah |
| 20:29 |
|
whartung |
awesome |
| 20:29 |
|
whartung |
that's the unix way |
| 20:29 |
|
trygvis |
yeah |
| 20:30 |
|
fumanchu_ |
played on the print head? ;) |
| 20:30 |
|
whartung |
You've never heard band printer music? |
| 20:31 |
|
trygvis |
:) |
| 20:34 |
|
fumanchu_ |
we had an issue here a couple months ago where our db engineer converted "ps -o rss=" output to audio to detect patterns in the allocation |
| 20:35 |
|
whartung |
oh do tell |
| 20:36 |
|
fumanchu_ |
I don't recall all the details, but he tuned the calls from the webserver to the db based on that...um...feedback |
| 20:36 |
|
whartung |
:) |
| 20:36 |
|
whartung |
"Servers are sounds a bit off key today..." |
| 20:36 |
|
fumanchu_ |
mostly to keep the CPU's more loaded |
| 20:36 |
|
whartung |
*sounding |
| 20:37 |
|
trygvis |
in the pre-cloud days you could just go to the server room and listen to the fans to hear the load |
| 20:37 |
|
whartung |
heh |
| 20:37 |
|
fumanchu_ |
https://www.youtube.com/watch?v=tDacjrSCeq4 |
| 20:37 |
|
fumanchu_ |
(mildly related) |
| 20:38 |
|
whartung |
wth... |
| 20:39 |
|
whartung |
wow |
| 20:39 |
|
whartung |
lol |
| 20:39 |
|
whartung |
that's really amazing. |
| 20:40 |
|
* fumanchu_ |
hasn't physically seen one of his servers since Etsy in 2008 |
| 20:40 |
|
whartung |
yea really |
| 20:53 |
|
ModusPwnens |
We have three endpoints that all take the same form of POST data. In this post data, however, is a 'type' field and there are three different 'types', with one endpoint associated with them. |
| 20:53 |
|
ModusPwnens |
Should the endpoints be consolidated into one and just take all three since it's all the same type of resource technically? |
| 20:53 |
|
ModusPwnens |
Example here: http://pastie.org/10302931 |
| 20:55 |
|
fumanchu_ |
typically, yes |
| 20:55 |
|
whartung |
all depends on where you want to do your routing, right? |
| 20:55 |
|
fumanchu_ |
the only time I wouldn't is if the three have different caching boundaries/lifetimes |
| 20:55 |
|
whartung |
you want the clients to do it, or the servers |
| 20:56 |
|
ModusPwnens |
That's what I figured. Is there some rest tenant somewhere that is related to or supports that? |
| 20:56 |
|
fumanchu_ |
if the clients do it, the servers end up having to validate more (make sure that cats/ agrees with pet_type: "cat") |
| 20:56 |
|
ModusPwnens |
wow, not tenant |
| 20:58 |
|
whartung |
eh, servers have to validate it anyway fumanchu_ :) |
| 20:58 |
|
fumanchu_ |
REST as an architectural style does not constrain whether there should be one or three endpoints. That's way too far down in the weeds. |
| 20:58 |
|
whartung |
si |
| 20:59 |
|
whartung |
gotta get all Reagan-esqe "trust, but verify" you client data :) |
| 21:00 |
|
fumanchu_ |
POST /pets/:id/cats looks strange anyway. What do you GET at that URI? |
| 21:00 |
|
ModusPwnens |
fumanchu_: I get that, but isn't it somewhat related to rest when you have several endpoints that accept the exact same kind of POST data? |
| 21:00 |
|
whartung |
no |
| 21:00 |
|
whartung |
you're talking application semantics now, not architectural |
| 21:01 |
|
fumanchu_ |
not really; that's more a question of how you want to design/expose any secondary indexes |
| 21:01 |
|
ModusPwnens |
Or is it OK to have several endpoints that accept the exact same kind of post data? |
| 21:01 |
|
ModusPwnens |
accept, not exact. Can't type today |
| 21:01 |
|
ModusPwnens |
oh wait, I can. I just can't read. |
| 21:01 |
|
whartung |
reading, typing, both are overrated on the internets :) |
| 21:02 |
|
ModusPwnens |
Because conceptually, aren't what you really doing with this is creating a Pet resource? And if you just did a POST to /pets, it would know how to create it based on the post data |
| 21:03 |
|
whartung |
I wouldn't type based on the URI |
| 21:04 |
|
fumanchu_ |
I could see a /pets/cats/ resource, but /pets/:id/cats doesn't make any sense to me. HTTP URI's are hierarchical, and I don't see how "cats" is a *subset* of "/pets/:id". An attribute, maybe, but not a subset. |
| 21:05 |
|
whartung |
unless :id is "karen" |
| 21:05 |
|
fumanchu_ |
the URI /pets/:id/cats looks like you're trying to give me a list of the cats my dog owns |
| 21:05 |
|
fumanchu_ |
nah, 'cause "karen" isn't a subset of pets |
| 21:06 |
|
whartung |
could be "karen's pets" |
| 21:06 |
|
fumanchu_ |
yeah. that's confusing too |
| 21:06 |
|
whartung |
Maybe the folks that came up with the URI is Japanese... |
| 21:06 |
|
whartung |
you and your english centric uri names!!! |
| 21:06 |
|
whartung |
OUTRAGEOUS! |
| 21:06 |
|
ModusPwnens |
fumanchu_: Yeah, that's actually an abstraction from our actual design and it was a poor abstraction apparently |
| 21:07 |
|
ModusPwnens |
But let's say it was /pets/cats. If you were creating a cat resource and cats have the exact same fields needed as creating a dog or a snake or any other type of pet, would you do a POST on /pets, or on /pets/cats? |
| 21:08 |
|
fumanchu_ |
it really comes down to caching patterns for me. if I'm a user and I GET /pets/cats and I POST a new cat, I probably want /pets/cats to be invalidated by the POST. |
| 21:08 |
|
ModusPwnens |
Or is it OK to have both? |
| 21:08 |
|
whartung |
it's ok to have both |
| 21:08 |
|
whartung |
who knows, the payloads may drift in time |
| 21:09 |
|
fumanchu_ |
but if pets/cats only responds to POST and I can't GET an index of cats there, it's spurious |
| 21:09 |
|
ModusPwnens |
knowing how things typically work around here, i'd bet that they will in any case. haha |
| 21:10 |
|
ModusPwnens |
Hmm okay. Thanks, fumanchu_ and whartung. This was helpful :) |
| 21:10 |
|
whartung |
there's also another point |
| 21:10 |
|
whartung |
"who cares" what the url is. |
| 21:10 |
|
whartung |
if they're the same right now, and need to change later, then the links should show that, and the apps won't care in the future anyway |
| 21:10 |
|
whartung |
the apps "don't know" what hte URL is, right? |
| 21:11 |
|
whartung |
so, "you can always change it" |
| 21:11 |
|
whartung |
that said |
| 21:11 |
|
whartung |
the lower the level the URL (i.e the closer to root), to more folks may tend to rely on it. |
| 21:11 |
|
ModusPwnens |
Sadly, this is not the case. We don't have hateoas stuff going yet. it's an uphill battle |
| 21:12 |
|
whartung |
I didn't expect you did, but I figured I'd toss it out anyway :) |
| 21:13 |
|
whartung |
just helps show how it can be beneficial. |
| 21:13 |
|
ModusPwnens |
We're still sort of at level 2, described in this doc: http://martinfowler.com/articles/richardsonMaturityModel.html |
| 21:13 |
|
whartung |
http://stackoverflow.com/questions/20335967/how-useful-important-is-rest-hateoas-maturity-level-3/20336307#20336307 |
| 21:15 |
|
fumanchu_ |
a better link: http://bit.ly/IqT6zt |
| 21:16 |
|
fumanchu_ |
(because "who cares" what the url is >;) |
| 21:22 |
|
whartung |
:D |
| 21:50 |
|
|
quimrstorres joined #rest |
| 22:00 |
|
|
fuzzyhorns joined #rest |
| 22:08 |
|
|
quimrstorres joined #rest |
| 22:13 |
|
|
ralphschindler joined #rest |
| 22:49 |
|
|
fuzzyhorns joined #rest |
| 23:06 |
|
|
quimrsto_ joined #rest |
| 23:20 |
|
|
fumanchu joined #rest |
