| Time |
S |
Nick |
Message |
| 00:38 |
|
|
MLMitch joined #rest |
| 02:40 |
|
|
MLMitch joined #rest |
| 02:42 |
|
|
proteusguy joined #rest |
| 03:40 |
|
|
MLMitch joined #rest |
| 04:10 |
|
|
fumanchu joined #rest |
| 04:11 |
|
|
lemur joined #rest |
| 04:26 |
|
|
tr3onlin_ joined #rest |
| 04:38 |
|
|
MLMitch joined #rest |
| 06:56 |
|
|
tr3online joined #rest |
| 07:31 |
|
|
xecycle joined #rest |
| 07:31 |
|
|
_ollie joined #rest |
| 07:35 |
|
xecycle |
Shall I reply to PUT the resource representation or 200/201/204 without body? |
| 07:38 |
|
|
lemur joined #rest |
| 07:38 |
|
trygvis |
xecycle: your choice |
| 07:39 |
|
xecycle |
trygvis: Okay; I tend to return nothing, and expect the client to issue another GET if the new resource is needed. |
| 07:41 |
|
trygvis |
I guess my stuff depends a bit on the kind of operation being done. if it's a crud-like thing I would return the resource, if not it's either no body (the operation implicitly succeeded) or an error document |
| 07:44 |
|
xecycle |
Well I implemented PUT as create or update. |
| 08:05 |
|
|
rosstuck joined #rest |
| 08:10 |
|
trygvis |
k |
| 08:10 |
|
trygvis |
I meant where you have more action like stuff, like 'send invoice' |
| 08:10 |
|
trygvis |
sometimes it makes sense to just return the invoice if it includes info on when it was sent, perhaps not |
| 08:11 |
|
xecycle |
Hum it's not. It is really a resource, which is created or replaced. |
| 08:12 |
|
xecycle |
And it fills some default values if missing. |
| 09:09 |
|
|
xecycle left #rest |
| 09:44 |
|
|
graste joined #rest |
| 10:01 |
|
|
martinfilliau joined #rest |
| 10:06 |
|
|
mezod joined #rest |
| 10:08 |
|
|
azer_ joined #rest |
| 10:12 |
|
|
proteusguy joined #rest |
| 10:22 |
|
|
marcoslamuria joined #rest |
| 10:25 |
|
|
Left_Turn joined #rest |
| 11:14 |
|
|
warehouse13 joined #rest |
| 11:25 |
|
|
azer_ joined #rest |
| 11:38 |
|
|
interop_madness joined #rest |
| 11:55 |
|
|
wsiqueir joined #rest |
| 12:25 |
|
|
azer_ joined #rest |
| 12:28 |
|
|
tr3online joined #rest |
| 12:40 |
|
|
Left_Turn joined #rest |
| 13:02 |
|
|
azer_ joined #rest |
| 13:30 |
|
|
rosstuck joined #rest |
| 13:57 |
|
mezod |
is it wrong to have diferent fields in the model representing the same object (i.e model for user) between the API model and the JS APP model? |
| 14:15 |
|
trygvis |
yesyes |
| 14:20 |
|
trygvis |
caching is an easy counter-argument for sending different responses |
| 14:20 |
|
trygvis |
but I would never share the interface between an 'api' and a JS app |
| 14:34 |
|
|
nkoza joined #rest |
| 14:38 |
|
|
MLMitch joined #rest |
| 14:39 |
|
|
marcoslamuria joined #rest |
| 15:00 |
|
|
marcoslamuria joined #rest |
| 15:04 |
|
|
marcoslamuria joined #rest |
| 16:04 |
|
|
fsvehla joined #rest |
| 16:19 |
|
|
warehouse13 joined #rest |
| 16:21 |
|
mezod |
trygvis: thanks! Do you know a good read on API REST User registration? I am not sure if I should return the token in the response of a register request...nor how to deal with email validation in this whole process..any hints would be much appreciated :P |
| 16:23 |
|
pdurbin |
mezod: return the user's token that the user can use on other API endpoints? is that what you mean? |
| 16:23 |
|
mezod |
pdurbin: yes |
| 16:25 |
|
pdurbin |
makes sense. I don't know how else you'd get the token to the user who just signed up. I assume there are sites out there that do this. |
| 16:26 |
|
mezod |
but if I return the token in the registration, then they already have full access... without even needing to validate their email |
| 16:27 |
|
mezod |
isn't there a standard on how to do this? |
| 16:27 |
|
pdurbin |
good point. sounds like a security/privacy problem |
| 16:27 |
|
trygvis |
mezod: I doubt many do that |
| 16:28 |
|
trygvis |
there are no generic method to sign up, so most people just do that on the outside and give the keys to their client though configuration |
| 16:28 |
|
pdurbin |
trygvis: log in through the web interface and copy your api token from there? yeah. that's what github does |
| 16:29 |
|
mezod |
trygvis: what do you mean by "through configuration"? |
| 16:29 |
|
pdurbin |
for API testing it's nice to get the token back right away after sign up. integration testing |
| 16:29 |
|
mezod |
this api is for a js app to consume, it's not that the users will manually grab the token to make requests on their own |
| 16:30 |
|
mezod |
so the behaviour from the user POV has to be as if any other website |
| 16:31 |
|
mezod |
I thought another option could be to generate the token during the register request, but not return it. Then in the mail activation attach the token somehow, so that when the user accesses from the link, he already has full access...but I have no clue of if this can be done at all :D |
| 16:36 |
|
trygvis |
mezod: most rest apps doesn't have session as a part of their state, the credentials are usually always present |
| 16:37 |
|
mezod |
i am not sure i follow |
| 16:37 |
|
mezod |
i am not using any session |
| 16:38 |
|
mezod |
all my endpoints require authorization via token. So I need a way to provide them with such token during registration :s |
| 16:38 |
|
pdurbin |
but still somehow valid their email address. tricky |
| 16:41 |
|
mezod |
i am not sure if I am doing something weird? I mean I thought this is what all SPA do? |
| 16:41 |
|
trygvis |
not really, it's actually a good place where you want to use REST |
| 16:42 |
|
trygvis |
I think most single page apps does authentication like they always have and after login you get the SPA |
| 16:42 |
|
trygvis |
and use the normal browser session to keep authentication |
| 16:43 |
|
mezod |
I'm so confused :d |
| 16:43 |
|
mezod |
"like they always have" |
| 16:43 |
|
mezod |
you mean that one thing is the html with the form and one other thing the spa, |
| 16:43 |
|
mezod |
right? |
| 16:44 |
|
trygvis |
yep |
| 16:44 |
|
trygvis |
after you post the form with your credentials you get a new html page with all the spa stuff |
| 16:44 |
|
mezod |
and where does this html page send its request? |
| 16:44 |
|
trygvis |
but you can also code all of this in the spa if you want |
| 16:45 |
|
trygvis |
you can include the start url as a part of the html body |
| 16:45 |
|
trygvis |
either as an inline JS fragement, or a form with hidden input elements |
| 16:50 |
|
mezod |
hmm and where would the request be sent if not the api? |
| 16:50 |
|
|
warehouse13 joined #rest |
| 16:51 |
|
trygvis |
why wouldn't it be sent to the api? |
| 16:54 |
|
mezod |
i guess i understood wrong |
| 16:54 |
|
mezod |
but i'm not getting anywhere |
| 16:55 |
|
mezod |
from the API POV it doesn't matter if the request comes from a js app or a simple html page |
| 16:58 |
|
saml |
if server has error, it's 5xx right? |
| 16:58 |
|
saml |
is there a good reason to send 404 (for SEO) |
| 16:59 |
|
|
MLMitch joined #rest |
| 17:02 |
|
|
azer_ joined #rest |
| 17:22 |
|
saml |
https://www.tumblr.com/tagged/asdfoajdoafjsidofjaodjfioaisodfj why is it 302? |
| 17:23 |
|
saml |
https://www.tumblr.com/tagged/restful but this is not |
| 17:23 |
|
saml |
if i'm building similar tag archive... is it better to have /tags/donotexist redirect to /search?q=donotexist? |
| 17:24 |
|
saml |
or should /tags/donotexist be 404? 400 even? |
| 17:31 |
|
|
MLMitch joined #rest |
| 17:43 |
|
|
tr3online joined #rest |
| 18:26 |
|
|
tr3online joined #rest |
| 19:04 |
|
|
tr3online joined #rest |
| 19:07 |
|
|
graste joined #rest |
| 19:47 |
|
|
ph88 joined #rest |
| 20:16 |
|
|
warehouse13 joined #rest |
| 21:09 |
|
|
tr3online joined #rest |
| 21:19 |
|
|
MLMitch joined #rest |
| 22:05 |
|
|
soulsurfer joined #rest |
| 22:06 |
|
|
cigarshark joined #rest |
| 22:14 |
|
|
soulsurfer joined #rest |
| 23:21 |
|
|
saml joined #rest |
