| Time |
S |
Nick |
Message |
| 00:37 |
|
|
timg___ joined #rest |
| 00:58 |
|
|
fuzzyhorns joined #rest |
| 02:59 |
|
|
fuzzyhor_ joined #rest |
| 11:47 |
|
|
_ollie joined #rest |
| 13:05 |
|
|
graste joined #rest |
| 14:33 |
|
|
tbsf joined #rest |
| 15:08 |
|
|
tbsf joined #rest |
| 15:37 |
|
|
rm- joined #rest |
| 15:39 |
|
|
tbsf joined #rest |
| 15:39 |
|
rm- |
Is it breaking the REST way of life to to post an empty body to /<entrypoint>/<id>/<doSomething> instead of posting with a body to /<entrypoint> with the data of { id: <id>, doSomething: true} ? |
| 15:42 |
|
rm- |
I guess the obvious answer would be 'yes'. But I'm considering doing it that way because the "easy way out". It's faster to code, easier to understand for others. |
| 15:48 |
|
pdurbin |
meh, it's probably ok |
| 15:55 |
|
rm- |
Problem with this approach I guess is - where does one draw the line and therefor it should go by the book? ;-) |
| 15:58 |
|
fumanchu |
REST is an architectural style (not a way of life ;) -- if your Pueblo-style rancho needs a doghouse, it doesn't have to have a flat roof |
| 15:59 |
|
rm- |
Or at least to reduce complaints from the asperger coders (which I'm part of myself so it's OK to joke about it). |
| 15:59 |
|
fumanchu |
draw the lines based on desired non-functional properties |
| 16:00 |
|
rm- |
fumanchu: Unfortunately my mustasche haven't grown as far down on each side of my mouth, so my non-native english toungue is a bit occupied with making the hair grow rahter than spending too much time finding the words. Sorry for my lack of vocuabular ;) |
| 16:01 |
|
rm- |
This specific case is activating an inactive module. So the rest-case would be either /modules/1/activate or /modules PUT: {id: 1, activate: true}. |
| 16:02 |
|
fumanchu |
no, those are the RPC cases |
| 16:02 |
|
rm- |
BLAST! I just can't get through to you, can I! /O\ |
| 16:04 |
|
fumanchu |
PUT /modules/1/ {"status": "activated"} would be a RESTful way to do it. Transfer a representation of the intended state. |
| 16:05 |
|
fumanchu |
(actualy, I'd recommend PATCH if you're only transferring part of the intended state) |
| 16:05 |
|
rm- |
status: "activated" seems more like the response to me. And of course... That's how it should be done. |
| 16:06 |
|
fumanchu |
that's the great thing about REST: requests and responses both transfer the same state and look awfully similar |
| 16:06 |
|
fumanchu |
but again, if that's not what you need, then don't worry about it: use RPC |
| 16:06 |
|
rm- |
I want to do it the RESTful way, that's why I felt I had to ask someone. |
| 16:08 |
|
rm- |
fumanchu: Could/Should "status" contain an object? |
| 16:08 |
|
rm- |
Or just a string? I mean. Status could also be updated, right... |
| 16:09 |
|
rm- |
And then - should response then contain the data that has been updated? |
| 16:09 |
|
|
tbsf joined #rest |
| 16:09 |
|
rm- |
*whew* |
| 16:09 |
|
|
fumanchu_ joined #rest |
| 16:09 |
|
rm- |
Noes! you missed my flood of questions >_< |
| 16:10 |
|
rm- |
Fear not. I can handle copy and paste \o/ |
| 16:12 |
|
rm- |
fumanchu_: I want to do it the RESTful way, that's why I felt I had to ask someone. Could/Should "status" contain an object or just a string? I mean. Status could also be "updated", right... |
| 16:14 |
|
fumanchu_ |
I don't know your domain, but I'm guessing if you had a verb "activate" that that moves a module from the "inactive" state to an "active" state. That is the state of the resource. You generally don't want to include control state like "updated"/"ok, I did what you asked" in the resource itself--that's what the HTTP response status code is for |
| 16:16 |
|
rm- |
Hmmm... Yeah. Good point. |
| 16:17 |
|
rm- |
But why should a certain update return a status update while other type of updates returns the new state? |
| 16:19 |
|
fumanchu_ |
all HTTP requests return a control status: 200 OK, 404 Not Found, 409 Conflict, etc |
| 16:19 |
|
rm- |
Yep, that's my point. |
| 16:22 |
|
fumanchu_ |
updates (POST, PUT, PATCH, DELETE) should not return the new state of the resource. clients generally won't expect it, because not every update command has a corresponding GET that returns what you POSTed. caches can't cache it. |
| 16:25 |
|
rm- |
Fair enough. However - that was not my point. My point was - why should type of update return a status update while others in the same domain responds with a http status code/what-have-you? |
| 16:26 |
|
fumanchu_ |
I guess I still don't follow. "others" is actually "all". I don't know what type of update "returns a status update" or doesn't "respond with a http status" |
| 16:27 |
|
fumanchu_ |
perhaps a concrete example would help |
| 16:28 |
|
fumanchu_ |
or is /modules/1/activate the example? |
| 16:30 |
|
|
tbsf joined #rest |
| 16:30 |
|
rm- |
Ok. Like this. I have Module ({ name: 'whatever', description: 'Lorem ipsum', active: false, author: 'Another Lipsum'}). When I do PUT:/modules/1 {description: 'Bacon Ipsum'} I repond with a 200 and that's that. But afaik you suggest that when doing PATCH /modules/1 {activate: true} I should respond with 200 {status: 'activated'}. What I don't seem to grasp is why one resource update should return one response |
| 16:31 |
|
rm- |
and another / all others only returns 200 without any data... |
| 16:31 |
|
fumanchu_ |
ah I see |
| 16:31 |
|
fumanchu_ |
I wasn't clear |
| 16:33 |
|
fumanchu_ |
my point was that when doing PATCH /modules/1 you should *send* {active: True} (an adjective, not "activate", a verb). The response should be 200 OK (or even 204 No Content) with no payload. |
| 16:33 |
|
fumanchu_ |
it might seem trivial to demand an adjective instead of a verb, but that in fact cuts to the heart of REST vs RPC |
| 16:34 |
|
rm- |
Ah, Payload is the word I'm eating my hair looking for. >_< thanks |
| 16:34 |
|
|
tbsf joined #rest |
| 16:34 |
|
fumanchu_ |
REST update says "here is the new resource or attributes". RPC says "modify the resource as I dictate". |
| 16:35 |
|
fumanchu_ |
(RPC update, that is) |
| 16:36 |
|
rm- |
Yeah, that I understood. What I didn't understand was the response... But now it seems like I totally misunderstood what you meant. I think we're on the same page again. |
| 16:36 |
|
fumanchu_ |
yay |
| 16:40 |
|
rm- |
Thanks a lot for your wise words. |
| 16:40 |
|
fumanchu_ |
not for the first time I wish there were a standard way of writing partial HTTP requests and responses on one line to avoid this kind of confusion :) |
| 16:41 |
|
fumanchu_ |
np, good luck! |
| 16:41 |
|
rm- |
Haha |
| 16:42 |
|
rm- |
Ready for another one? ;) |
| 16:42 |
|
fumanchu_ |
....maybe :) |
| 16:42 |
|
rm- |
Patch only takes part of the resource that should be updated while PUT should receive the whole resource - right? |
| 16:43 |
|
fumanchu_ |
mostly, yes |
| 16:43 |
|
fumanchu_ |
lots of "excepts" there |
| 16:43 |
|
rm- |
It seems like most people are using PUT most of the time and barely every uses PATCH (no sources to cling onto about that statement tho) ;) |
| 16:44 |
|
fumanchu_ |
yes, it's common |
| 16:44 |
|
fumanchu_ |
for a host of reasons |
| 16:44 |
|
rm- |
Less code less bugs seems like the best argument to me... |
| 16:46 |
|
rm- |
But then one should use PATCH by default? Cause updating the whole resource would be equal to PUT (with the difference being that it's different HTTP request types) |
| 16:47 |
|
fumanchu_ |
the original use-case for PATCH was not to send part of the resource, but instead to send instructions in some other media type, like sending a .diff file to a .txt resource |
| 16:47 |
|
fumanchu_ |
JSON has mostly blurred that line |
| 16:48 |
|
rm- |
Yeah... That would explain the verb name... |
| 16:48 |
|
fumanchu_ |
(and in rigorous media types like my Shoji, PATCH takes the same media-type) |
| 16:49 |
|
fumanchu_ |
but the remaining big difference between PATCH and PUT is that PUT is allowed to create the resource if it does not already exist, and PATCH isn't |
| 16:49 |
|
rm- |
Aha! |
| 16:51 |
|
rm- |
hidden usecase *DING* taking notes... Cheers |
| 16:52 |
|
rm- |
Or rather shaded... Anywho... Thanks again! |
| 16:52 |
|
fumanchu_ |
np |
| 16:52 |
|
rm- |
This is FUN \o/ |
| 16:52 |
|
fumanchu_ |
:D |
| 17:26 |
|
|
tbsf joined #rest |
| 18:41 |
|
|
tbsf joined #rest |
| 19:48 |
|
|
DracoBlue joined #rest |
| 21:18 |
|
|
DracoBlue joined #rest |
| 22:28 |
|
|
tbsf joined #rest |
| 23:17 |
|
|
wCPO joined #rest |
| 23:17 |
|
wCPO |
On error, is it "okay" only to return a status code? or should I also return some sort of error message inside json? |
| 23:22 |
|
fumanchu_ |
okay, not great, although it depends on the error |
| 23:22 |
|
fumanchu_ |
returning some kind of payload that tells the user or client developer what went wrong and how to go about fixing it is always nice |
| 23:28 |
|
|
tbsf joined #rest |
