greptilian logo

IRC log for #rest, 2014-12-12

#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:38 shrink0r joined #rest
01:43 shrink0r_ joined #rest
02:03 PalyaPix joined #rest
02:45 codeisgreat joined #rest
02:47 lemur joined #rest
03:51 tr3onlin_ joined #rest
04:03 proteusguy joined #rest
04:29 shrink0r joined #rest
04:33 gluegadget joined #rest
04:34 lebster joined #rest
04:39 shrink0r_ joined #rest
04:48 lemur joined #rest
05:07 tr3online joined #rest
05:47 PalyaPix joined #rest
05:58 codeisgreat joined #rest
06:39 proteusguy joined #rest
06:45 shrink0r joined #rest
07:23 lemur joined #rest
07:28 codeisgreat joined #rest
07:33 lemur joined #rest
08:06 dreamdust_ joined #rest
08:32 Andre-B joined #rest
08:34 shrink0r joined #rest
08:54 fumanchu joined #rest
09:10 graste joined #rest
09:11 tr3online joined #rest
09:11 fumanchu_ joined #rest
09:26 lemur joined #rest
09:36 interop_madness joined #rest
09:49 mezod joined #rest
10:11 Andre-B_ joined #rest
10:16 martinfilliau joined #rest
10:18 marcoslamuria joined #rest
10:23 interop_madness is HATEOAS by means of the Link header field (RFC 5988) a bad idea? considering http://en.wikipedia.org/wiki/HATEOAS#Details ,  can/should the <link> tags be moved to the Link header field instead?
10:23 shrink0r joined #rest
10:24 interop_madness the way i understand all this (hint: i don't quite), HATEOAS via Link header field has the advantage that the link relations are independent of serialization
10:53 tr3online joined #rest
10:58 mezod joined #rest
10:58 tr3online joined #rest
11:08 Left_Turn joined #rest
11:16 trygvis woop
11:17 trygvis interop_madness: IMO the link header is a suppliment for media types that can't embed links
11:19 interop_madness trygvis, but suppose the XML representation of a resource adheres to an XSD that does not allow placing <link> tags inside the XML. this would then be a case for the link header, right?
11:21 trygvis yes
11:22 trygvis xml is not a very useful hypermedia. atom (xml-based) is a more useful hypermedia
11:25 _ollie joined #rest
12:05 shrink0r joined #rest
12:20 Left_Turn joined #rest
12:44 pdurbin what's the difference between xml and xml-based? how is atom not xml?
12:50 trygvis xml doesn't specify how you're supposed to process the different element, atom does
12:52 pdurbin ok
13:03 mezod joined #rest
13:03 martinfilliau joined #rest
13:15 martinfilliau joined #rest
14:01 mezod joined #rest
14:37 nkoza joined #rest
14:46 znn joined #rest
15:02 hio joined #rest
15:03 hio hi guys, im a little unsure on how to make my webapi. It has a LOT of options to configure (around 15, and lots of key-value pairs that people may want to add).. I mean, it would be so much nicer to make this into a POST request with a json body. But it's literally just a GET, with *maybe* an option to forcefully update the cache. What should I do?
15:06 hio if you know such apis, they can get confusing very quickly and there's no auto format for these huge query strings. For example see an example (simpler...)  rally rest api: https://rally1.rallydev.com/slm/webservice/v2.0/task?query=((Owner.Name%20=%20myemail@gmail.com)%20and%20(State%20!=%20Completed))&order=Rank&fetch=true&stylesheet=/slm/doc/webservice/browser
15:11 mezod joined #rest
15:13 saml joined #rest
15:29 ralphschindler joined #rest
15:29 ralphschindler joined #rest
15:33 znn joined #rest
15:35 DacFarren joined #rest
15:39 DacFarren Hey... can I provide authorization to some request just using http basic auth?
15:50 saml sure
15:51 saml what are you trying to do? they are different things
16:18 dreamdust joined #rest
16:22 Andre-B joined #rest
16:38 fumanchu_ hio: *every* time someone has asked for that in an API I'm involved with, it turns out there are less than 4 specific combinations people are actually interested in. The vast majority of the time, it's 1! Name those combinations and expose them as separate resources.
16:38 fumanchu_ generality is overrated
16:38 hio you mean i should hardcode combinations?
16:38 hio that doesnt seem good
16:38 fumanchu_ yes
16:40 hio for example i have resources of type X and X has properties like Name, Description, Content. Now someone needs to be able to query all resources with Name starting with "hello*" and Content containing the word "blub"
16:40 hio any kind of regex should be allowed..
16:40 hio so hard coding that is not really possible
16:40 fumanchu_ why do they need to do that? what is their application?
16:41 fumanchu_ ask those questions and you'll usually find they have a tiny number of use cases
16:41 hio well it's like a remote database access
16:41 hio they literally want access to my database objects. Which is fine, but these database objects have lots of properties.. and they obviously want to filter on them, sort of like doing their own SQL
16:41 fumanchu_ ah one of those
16:43 hio right now I think I have found an acceptable solution by allowing query strings like this: user[name][first]=Tobi&user[name][last]=Kurt
16:43 hio it reads OK and allows a lot of complexity
16:43 fumanchu_ yeah
16:45 fumanchu_ so the most important thing to understand about such API's is: you don't want REST. When the client has nearly infinite configurability, things like scale and evolvability go right out the window
16:46 fumanchu_ your design looks fine. I would use e.g. user.name.first just to cut down on chars
16:46 hio I thought about that, but it reads slightly worse
16:47 fumanchu_ if I were making it, I would seriously push back on generality
16:47 fumanchu_ watch your server logs and see. you'll find a dozen or so of the same queries being called over and over with only a couple values changing
16:47 hio well, like I said I dont see how. Do you have some example in mind on how that would look?
16:49 hio i think the small usecases wouldnt even be that bad. /?user.name="Tom"&user.age>18 or something like that. I was just thinking about GET vs. POST in general. it's a lot easier to write json than these query strings
16:49 hio however with a GET request without a body you can make bookmarks in your browser, which is really nice..
16:50 fumanchu_ you'll see general?user[name][first]={fi​rst}&user[name][last]={last} a million times and say "why didn't I just expose users/by/name?Tobi+Kurt?"
16:51 fumanchu_ json in the qs is fine. be careful about clients encoding lots of whitespace
16:51 fumanchu_ and your intuition is correct to favor GET over POST for this
16:53 fumanchu_ you can cache users/{name} and have it invalidated when you POST changes. you can't do that with general?user[name][first]={first}...
17:14 DacFarren saml: about the http basic auth, take for example some applications that has rest apis, say sonarqube
17:15 DacFarren you have a bunch of users that can consult to that api, but not everyone are allow to access some of the services, say system info service
17:15 DacFarren I now it uses basic auth
17:15 DacFarren but dont know hoy they achieve authorization
17:16 saml authorization is up to your app
17:16 saml authentication verifies the client is who it says it is
17:17 saml you can "personalize" your resources based on client's identification
17:19 znn joined #rest
17:33 DacFarren saml: ok, could be then organize users by different groups. and app responds to groups while, authenticating, if the user dont belong to the group
17:34 DacFarren is unauthorize to use the app or api
17:35 DacFarren isnt that a little bit like saml?
17:36 saml i guess. it really all depends , i think
17:36 saml i just block certain resources like  /foo/bar   to all users but admin
17:39 hio hm weird, it seems browser can work fine with query strings that contain full json... why doesnt anybody use that then? like this: www.google.com/?myrequest={"hi":"test"}
17:39 hio instead everybody seems to use these ugly as hell query strings
17:47 fumanchu_ hio: we use it here :)
17:48 fumanchu_ again, though, watch out for lots of ++++++++ in your json query strings if you're not careful about whitespace
18:01 tr3online joined #rest
18:07 DacFarren what if the api is constantly called by a frontend application, how can I safely store the credentials
18:07 DacFarren knowing that the app is going to send the credentials for every request it makes to the api
18:19 whartung define "safely"?
18:29 hio fumanchu_ yes I decided to use it too, I was just wondering about using it *without* escaping, apparently browsers do that implicitly.
18:29 hio the browser itself does not care if i use a raw json in the url
18:29 hio anyway, i have to go. thanks for everything
18:32 DrCode joined #rest
18:39 jackalista joined #rest
19:30 proteusguy joined #rest
19:46 shrink0r joined #rest
20:08 shrink0r joined #rest
21:30 ralphschindler joined #rest
21:40 graste joined #rest
21:44 HighBit joined #rest
21:45 Andre-B joined #rest
22:03 lemur joined #rest
23:36 shrink0r 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.