| 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 |
