greptilian logo

IRC log for #rest, 2015-02-13

https://trygvis.io/rest-wiki/

| Channels | #rest index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary

All times shown according to UTC.

Time S Nick Message
00:40 ewalti joined #rest
01:09 shrink0r_ joined #rest
01:21 diegoaguilar joined #rest
01:45 fumanchu_ joined #rest
02:16 talios joined #rest
05:06 lemur joined #rest
07:10 proteusguy joined #rest
07:30 diegoaguilar joined #rest
08:37 azr joined #rest
08:47 proteusguy joined #rest
08:54 shrink0r joined #rest
08:56 interop_madness joined #rest
09:25 mezod joined #rest
10:04 Tobbe left #rest
10:07 BrunoCosta joined #rest
10:09 ewalti joined #rest
10:31 Left_Turn joined #rest
10:58 rosstuck joined #rest
11:28 shrink0r_ joined #rest
12:21 shrink0r joined #rest
12:40 shrink0r_ joined #rest
12:46 mezod joined #rest
12:51 shrink0r joined #rest
12:59 azr joined #rest
13:24 azr joined #rest
13:26 shrink0r_ joined #rest
13:32 shrink0r joined #rest
13:34 shrink0r_ joined #rest
13:49 Andre-B joined #rest
14:04 mezod joined #rest
14:28 nkoza joined #rest
15:05 foist joined #rest
15:09 mezod joined #rest
15:09 ralphschindler joined #rest
15:29 shrink0r joined #rest
16:08 shrink0r_ joined #rest
16:24 zama joined #rest
16:54 ralphschindler joined #rest
17:05 foist Could someone tell me how error conditions should be treated in my REST endpoints? Should the body indicate an internal error code and a brief message, or is the HTTP status code enough?
17:23 lemur joined #rest
17:30 fumanchu_ the HTTP status code is enough to fail in the right way. if you want to give the client recovery or navigation options, you generally want those in the response body (as the HTTP status code specs tell you you do ;)
17:30 whartung yea
17:35 lemur joined #rest
17:36 foist fumanchu_: what do you mean by recovery options?
17:37 asdf` foist, that's a business logic level thing; eg. if you fail to save something, have your server propose valid alternatives
17:38 foist The scenario I’m dealing with is that posting to foo/1 doesn’t work, because 1 doesn’t exist. It returns a 404 {“detail”: “Not found”} at present, but the mobile dev is asking for more detail in the response body.
17:38 fumanchu_ 409 Conflict is the canonical example. you can sometimes return a body with "click here to resolve the conflict in this way, or here another way"
17:38 foist I’m saying that a 404 status code is informative enough. The context from which the call was made should be enough for the client to know how to handle the 404.
17:39 fumanchu_ in your case, 404 is enough for the mobile dev to stop processing. the option is now yours to delight the client with alternatives.
17:39 asdf` foist, (also remember you can use 404 or 410; that's one additional bit of information right there)
17:40 fumanchu_ time for Clippy to say "looks like you're trying to POST to a non-existent foo. You first need to PUT to foo/1 before you can POST.
17:40 foist There are no alternatives. In the classic blog example, they’re trying to post a comment to an article that doesn’t exist.
17:40 fumanchu_ yep, sometimes there really aren't any alternatives
17:41 fumanchu_ I always find it enlightening trying to think of some anyway
17:41 fumanchu_ even if it's just a link to go back up a level
17:42 fumanchu_ "hypertext as the engine of application state" means the client should never just stop processing until they're done with what they want to do. the server should give them options on what to do next
17:47 ewalti joined #rest
17:57 foist Is there anything wrong with displaying the respond body returned by the server during error conditions to the client directly?
17:58 foist Like if the client receives a 404, should the client app provide its own message to the user, or is passing the message along okay?
17:59 fumanchu_ in theory, there's nothing wrong with that. but in practice, server developers tend to write end-user-unfriendly messages ;) and the client can typically internationalize better
18:00 fumanchu_ which really means in my experience, it comes down to the budget for each side ;)
18:00 foist That’s basically what it is with us right now.
18:00 foist I’m saying it’s a bad idea. They’re saying it’s a budget thing.
18:01 fumanchu_ you're both right, then
18:01 foist I think that makes us both wrong.
18:01 azr joined #rest
18:01 foist I should be working within the budget; they should be providing enough budget to do things right.
18:04 fumanchu_ they get to determine what's "right", though. if you think their current view of what's right for them isn't aligning with their objectives, then you can tell them that. but generally you don't get to determine their objectives. such is life.
18:06 fumanchu_ (trying to sympathize without enabling ;)
18:19 csgeek joined #rest
18:20 csgeek how do people handle passing array for webservices.  POST that is.  comma delimited? is there a preferred convention?
18:22 shrink0r joined #rest
18:29 shrink0r_ joined #rest
18:31 lacrymology joined #rest
18:34 lacrymology how bad of an idea is to add a request body to a DELETE endpoint, like `DELETE /path/to/resource` body: [{id: foo}, {id:bar}]
18:34 lacrymology to be able to batch requests
18:42 azr_ joined #rest
18:47 cythrawll joined #rest
18:48 fumanchu_ pretty bad. there have been plenty of HTTP proxies and such that won't pass on payloads in a DELETE request.
18:48 fumanchu_ see https://tools.ietf.org/html/rfc7231#section-4.3.5
18:49 shrink0r joined #rest
18:51 shrink0r_ joined #rest
19:53 shrink0r joined #rest
20:02 graste joined #rest
20:03 proteusguy joined #rest
21:04 azr joined #rest
21:14 shrink0r joined #rest
22:15 lacrymol1gy joined #rest
23:03 azr joined #rest
23:04 azr_ joined #rest
23:41 chowmeined__ joined #rest
23:56 lacrymology joined #rest

| Channels | #rest index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary

https://trygvis.io/rest-wiki/