Time  Nick            Message
10:13 rincewind666    I have a resource that is posted somewhere (r1). And then I want to post that I have a relationship to that resource on another resource (r2). So I would like to post the id for that relationship. Would I do post api/r2/r1 with id (or ref_id) in body, or would i do post api/r2/ref_r1 with id in body?
10:14 trygvis         you don't post IDs, you post URIs
10:14 trygvis         you download r2, add the reference to r1 and POST r2 back to the server
10:26 rincewind666    ah, ok - thanks!
10:27 rincewind666    great answer
10:45 Guest86856      Trying to get my head around a concept in REST. How do you deal with resources that have inter-dependencies, and maintaining data integrity? (like cascades if thinking in sql terminology)?
10:49 trygvis         usually you make your resources coarse grained and self-consistent and use that as your resource type
10:58 Guest86856      trygvis: so, for example, what if there was a "tag" resource and a "photo" resource, where photos have tags, and you want to ensure that if a DELETE is issued on a tag, it only succeeds if that tag doesn't exist on any photos - I don't really get how to express such a system with REST?
12:49 interop_madness should empty sets be represented by http/404 or should the serialization account for empty sets? consider http://server/people/126510/relatives: what if 126510 has no relatives? suppose i request with Accept: application/vnd.peoplelist+xml, theoretically a http/200 response with body <People></People> would be possible
12:50 interop_madness what would also be possible is http/404, suggesting "no relatives found"
12:51 trygvis         I would guess most hypermedias have support for empty sets
13:39 interop_madness trygvis, so it's recommended to return 200 OK with an empty set instead of 404?
13:41 trygvis         I don't know if I can find a citation for it, but 404 usually indicates that the client did something silly
13:41 trygvis         it's not like the list is not there, it's just empty
13:41 trygvis         so I would definitely go for 200
14:17 interop_madness ok tanks
14:17 interop_madness +h
21:18 pdurbin         HTTP POST with URL query parameters -- good idea or not? - Stack Overflow - http://stackoverflow.com/questions/611906/http-post-with-url-query-parameters-good-idea-or-not
21:18 pdurbin         any opinions? :)
21:18 gamache         I've never had a problem with URL params on a POST/PUT/PATCH
21:23 gamache         I try to design my APIs so that they are usable from awful and perverse environments
21:23 gamache         I can imagine a situation where it is convenient to put certain params on every request, and that's easier to do in the URL
21:25 pdurbin         I'm hearing that https://code.google.com/p/rest-assured/ says the equivalent of "not a good idea". Won't let you do it.
21:29 gamache         that sounds annoying
21:30 gamache         I often dislike opinionated testing tools
21:31 gamache         anyway this Stack Overflow post is specifically about having an empty POST body and all the payload on the URL
21:32 gamache         that sounds kind of stupid in its contexxt
21:42 pdurbin         well, I haven't tried it myself yet.
21:43 fumanchu_       stop reading W3C specs and read IETF ones. then query *strings* are just part of the URI and the method is irrelevant.
21:47 fumanchu_       everything before the # identifies the target resource
23:16 pdurbin         fumanchu_: so you're saying POST with whatever in the URI (including query strings) is fine
23:17 fumanchu_       yep
23:20 pdurbin         ok
23:42 whartung        most frameworks do not distinguish between arguments in the URL and arguments in teh payload, especially if the arguments in the payload are form encoded.
23:44 pdurbin         I'll have to play around with rest-assured some more. So far I like it.