Time Nick Message 23:44 pdurbin I'll have to play around with rest-assured some more. So far I like it. 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:20 pdurbin ok 23:17 fumanchu_ yep 23:16 pdurbin fumanchu_: so you're saying POST with whatever in the URI (including query strings) is fine 21:47 fumanchu_ everything before the # identifies the target resource 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:42 pdurbin well, I haven't tried it myself yet. 21:32 gamache that sounds kind of stupid in its contexxt 21:31 gamache anyway this Stack Overflow post is specifically about having an empty POST body and all the payload on the URL 21:30 gamache I often dislike opinionated testing tools 21:29 gamache that sounds annoying 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: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:23 gamache I try to design my APIs so that they are usable from awful and perverse environments 21:18 gamache I've never had a problem with URL params on a POST/PUT/PATCH 21:18 pdurbin any opinions? :) 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 14:17 interop_madness +h 14:17 interop_madness ok tanks 13:41 trygvis so I would definitely go for 200 13:41 trygvis it's not like the list is not there, it's just empty 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:39 interop_madness trygvis, so it's recommended to return 200 OK with an empty set instead of 404? 12:51 trygvis I would guess most hypermedias have support for empty sets 12:50 interop_madness what would also be possible is http/404, suggesting "no relatives found" 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 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? 10:49 trygvis usually you make your resources coarse grained and self-consistent and use that as your resource type 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:27 rincewind666 great answer 10:26 rincewind666 ah, ok - thanks! 10:14 trygvis you download r2, add the reference to r1 and POST r2 back to the server 10:14 trygvis you don't post IDs, you post URIs 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?