greptilian logo

IRC log for #rest, 2015-08-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:13 fuzzyhorns joined #rest
00:55 linux_dr joined #rest
00:56 fuzzyhorns joined #rest
01:02 Davey joined #rest
02:54 baweaver joined #rest
03:01 fuzzyhorns joined #rest
05:44 linux_dr joined #rest
07:22 interop_madness joined #rest
07:43 metasansana joined #rest
07:43 mamund joined #rest
07:43 vlakarados joined #rest
07:43 gamache_ joined #rest
07:43 alxbl joined #rest
07:43 EnergyCoffee joined #rest
07:43 mamund_ joined #rest
07:46 EnergyCoffee joined #rest
07:47 gamache joined #rest
07:48 alxbl joined #rest
07:48 vlakarados joined #rest
08:04 Coldblackice joined #rest
08:10 graste joined #rest
08:13 Left_Turn joined #rest
08:37 chthon joined #rest
08:56 quimrstorres joined #rest
08:59 StatelessCat joined #rest
09:05 quimrstorres joined #rest
09:08 fumanchu joined #rest
09:12 m_foobar joined #rest
09:12 m_foobar left #rest
09:43 fumanchu_ joined #rest
09:58 angular_mike_ I need to implement a way to check whether resource creation is 'feasible', basically, something that checks whether the back-end is able to create it, using the given POST payload. What is a good way to do this?
09:59 angular_mike_ e.g., what about making 'POST to collection/feasibility_check_jobs {resource payload}'
10:00 asdf` angular_mike_, why not simply create it right then? and possibly fail to create
10:00 angular_mike_ the important thing is that it doesn't actually create the resource
10:00 asdf` oh, why is that important, then?
10:01 asdf` one pattern is to create the thing, but leave it in an 'unpublished' state, requiring another update to it before it is visible by others
10:02 angular_mike_ asdf`: to avoid comitting
10:02 angular_mike_ asdf`: to check whether you can afford commitiing
10:13 fumanchu joined #rest
10:17 pokEarl joined #rest
11:24 quimrstorres joined #rest
13:39 quimrstorres joined #rest
13:55 quimrstorres joined #rest
15:22 pdurbin whartung: I'm looking for that article about async
15:24 pdurbin ah, here it is: https://dzone.com/articles/is-asynchronous-ejb-just-a-gimmick
15:48 quimrstorres joined #rest
16:27 whartung yea thats it
16:27 whartung pdurbin
16:27 whartung I sitl haven't read it
16:32 pdurbin whartung: shame on you
16:33 pdurbin I may need to back out of my async experiments: https://github.com/IQSS/dataverse/issues/2453
16:35 fumanchu_ joined #rest
16:41 quimrstorres joined #rest
17:09 quimrstorres joined #rest
18:05 cvander joined #rest
18:37 foist joined #rest
18:38 foist Is creating different api “groups” for different interfaces/user-cases considered an anti-pattern? For instance, /api/dashboard, /api/mobile, etc.
18:38 foist use*-cases
18:39 whartung just resource name foist, call them what you like
18:39 whartung *names
18:40 foist No, those aren’t the resource names, those are the groups.
18:40 foist /api/dashboard/foo, /api/mobile/foo
18:41 foist I guess that should be foos*
18:42 foist whartung: ^
18:43 whartung no -- they're resource names.
18:43 whartung since, that's all REST deals with is … resource names.
18:44 whartung afk bbl
18:44 foist hmm
18:44 foist I thought RESTful API end-points should be client-agnostic.
18:50 asdf` foist, it doesn't really have all that much to do with REST, more with general programming; you can have two sets of resources that happen to be backed by the same data, but it probably won't make very much sense
18:51 asdf` as in, why the foos in dashboard would be different than the foos in mobile?
19:28 metasansana joined #rest
22:14 Coldblackice joined #rest
22:21 pdurbin whartung: please do let me know when you've read it. pushed a fix for my async woes
22:33 fuzzyhorns joined #rest

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

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