| 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]={first}&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 |
