greptilian logo

IRC log for #rest, 2014-07-30

#rest on freenode has been logged here from May 2014 until end of July 2018 but logging has been suspended because the channel has been riddled with spam since August 2018 with no end in site. See the following blog posts about the problem:

Until the spam problem has been dealt with and logging can resume, please visit our wiki at https://trygvis.io/rest-wiki/

Thanks.

| 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 talios joined #rest
01:14 charlex joined #rest
01:47 gtramontina joined #rest
01:51 wilmoore joined #rest
02:57 DrCode joined #rest
04:19 mikehaas763 joined #rest
04:23 mikehaas763 I have a resource (ClassSections) where a user needs to be able to define the relationships to other resources (teachers, timeblocks and rooms). What would be a good convention for the requests to create a new ClassSection? POST /class-sections {roomId: 1, teacherId: 1, timeblockId:1} for example
04:25 ocx left #rest
05:20 _ollie joined #rest
06:47 ph88 joined #rest
06:54 wilmoore joined #rest
07:17 orriols joined #rest
08:02 fumanchu_ joined #rest
08:46 _ollie joined #rest
09:03 fumanchu joined #rest
09:05 interop_madness joined #rest
09:06 martinfilliau joined #rest
09:44 trygvis_ joined #rest
09:45 fumanchu_ joined #rest
09:49 alxbl joined #rest
10:12 shrink0r joined #rest
11:00 martinfilliau joined #rest
11:45 ingsoc joined #rest
11:45 ingsoc POST made to api/device_id/vehicle_checks v api/vehicle_checks/device_id v api/vehicle_checks (the payload/body contains device_id in message)
11:45 ingsoc just wondering if anyone here with REST experience could let me bounce ideas off ?
12:17 jcromartie joined #rest
12:48 charlex joined #rest
13:17 DrCode joined #rest
13:18 jcromartie joined #rest
13:46 DrCode joined #rest
13:48 interop_madness are there some (semi-)established resource lifetime/retention time semantics for REST services? i.e. i POST a content and want to specify how long it should be available, or i GET a resource and some header tells me how long this resource will be available...
14:12 fumanchu_ ingsoc: what is the meaning of what the client POSTs, and what is the client's intent by POST'ing it?
14:15 igitoor joined #rest
14:15 igitoor joined #rest
14:17 gtramontina joined #rest
15:24 danielemm joined #rest
16:06 systmkor1 joined #rest
16:09 fumanchu joined #rest
16:11 wilmoore joined #rest
16:17 gtramontina joined #rest
16:19 systmkor1 joined #rest
16:24 fumanchu joined #rest
17:02 systmkor2 joined #rest
17:34 ingsoc fumanchu_: POST creates a new record/resource
17:35 ingsoc looks like twitter uses a query string as the data for a new tweet.  what do others usually do ?, have a JSON payload in the body with the data ?
17:36 fumanchu does it create a new "vehicle check" resource?
17:41 ingsoc fumanchu: yes
17:42 ingsoc do i bother with the device_id, if this can be gotten from the body payload(JSON)
17:43 fumanchu if you're adding a new "vehicle check" resource to a "vehicle checks" collection, you typically want to POST to vehicle_checks/, not some other URI
17:43 fumanchu (that way, any cached copy of vehicle_checks/ gets invalidated)
17:44 fumanchu which leads you to put the device_id in the payload
17:44 ingsoc ok, there are a number of vehicles, and each day a vehicle_check report is created
17:44 fumanchu instead of the path
17:44 ingsoc for each vehicle, does it make sense to have the vehicle_id in the resource path
17:44 alxbl joined #rest
17:44 ingsoc or have it determined by the payload of the JSON/Body
17:45 ingsoc ok
17:46 fumanchu does a vehicle check report correspond to just one vehicle, or all vehicles for that day?
17:46 fumanchu if just one, I would expect api/vehicles/{id}/report
17:47 fumanchu if more than one, I would expect api/vehicle_checks/{vehicle_check_id}
17:48 ingsoc yes, a vehicle report corresponds to one vehicle, and there are many vehicles each having a vehicle check per day
17:49 ingsoc at the moment i have chosen...
17:49 ingsoc api/vehicle_checks and the body has a JSON payload containing a vehicle check report which includes the vechile_id
17:49 ingsoc vehicle_id*
17:50 fumanchu that sounds perfectly fine
17:51 ingsoc there is other data relating to a vehicle also like  like position_data
17:51 ingsoc (gps positional information)
17:51 ingsoc so maybe an argument could be made for also
17:51 ingsoc api/device_id/vehicle_checks
17:51 ingsoc api/device_id/position_data
17:52 ingsoc or just also do api/position_data and get the device_id from the JSON payload
17:52 ingsoc does it really matter ?
17:52 ingsoc i dunno
17:52 fumanchu what is a "device"?
17:53 fumanchu is that the same as "vehicle id"?
17:55 ingsoc fumanchu: good question, making me think about what I am doing.  OK, I need to think about this a bit more.
17:55 fumanchu np :)
17:55 fumanchu typically, the answer to whether to do foos/{foo}/bars/{bar}/ or bars/{bar}/foos/{foo}/ is really up to the more common expected client need
17:56 ingsoc I control client and server so i spose i can be more flexible
17:56 fumanchu however, you should make one or the other canonical just to get the caching right, and have the other redirect to it
17:56 ingsoc but I MAY have to open this up to 3rd parties at a later date
17:57 ingsoc so, obviously it would be useful to at least get something coherent up and running
17:57 ingsoc :)
17:57 ingsoc ok, while we are on the topic of caching
17:57 ingsoc how do you handle date ranges
17:57 ingsoc as i understand it, any time there are query strings
17:57 ingsoc caching is blown
17:58 ingsoc some_data/from/yyyy/mm/dd/to/yyyy/mm/dd ?
17:58 ingsoc or like most people
17:58 ingsoc some_data?from=yyyy-mm-dd&to=yyyy-mm-dd
17:59 ingsoc fumanchu:
17:59 ingsoc ^
17:59 fumanchu putting y/m/d in the path instead of the querystring makes caching only slightly easier
18:00 fumanchu the problem with putting it in the qs is that a lot of clients (and even servers) will randomize the order of params in the qs
18:00 fumanchu and each distinct combination refers to a different URI
18:00 fumanchu so they will be cached separately
18:00 ingsoc I was under the impression that QS where just not cached at all in intermediary
18:00 fumanchu putting y/m/d in the path at least solves that problem
18:00 fumanchu it depends on the intermediary
18:00 ingsoc (I am still a noob btw)
18:00 fumanchu squid used to not cache anything with a qs by default
18:01 fumanchu but a) that's always configurable and b) I think it changed a while back
18:01 fumanchu browser caches have gotten a *lot* better about that
18:02 fumanchu http://stackoverflow.com/a/4411929
18:02 ingsoc fumanchu: well, my knowledge is probably outdated then and needs updating :)
18:03 ingsoc i assume content-type is factored into caching
18:03 ingsoc same url but different content-type
18:03 ingsoc is 2 cahces
18:03 fumanchu only if mentioned in the Vary header
18:03 ingsoc caches
18:03 ingsoc oh crap
18:03 ingsoc i return msgpack or json
18:04 ingsoc any good info on caching ?
18:05 fumanchu sorry, I misspoke
18:05 ingsoc I am hoping that caching, if used correctly will significantly offload processing
18:05 ingsoc i basically want to server a resource up once
18:05 ingsoc if possible
18:05 fumanchu always a worthy goal :)
18:06 fumanchu anyway, you need to Vary on the *request* headers
18:06 fumanchu how do you determine whether to return msgpack or json?
18:07 ingsoc accept
18:07 ingsoc header
18:07 fumanchu ok, then you need your response to include the header "Vary: Accept"
18:07 fumanchu or caches won't differentiate
18:07 ingsoc thanks for the heads up.
18:08 ingsoc I am hoping that leaning on caching could help reduce load on the system
18:09 ingsoc does being cache friendly have potential for this kind of reward ?
18:09 fumanchu oh yes
18:09 ingsoc the great thing about the vehicle reports and gps tracking data is that it NEVER changes
18:10 ingsoc once written, that is it
18:10 fumanchu I've been working on systems for 10 years that would not survive without HTTP caching
18:10 ingsoc perfect for cacheing
18:10 fumanchu the Holy Grail!
18:10 ingsoc exactly
18:10 fumanchu Expires: never! <evil cackle>
18:11 ingsoc ok, but will that only affect the browser that already has the resource or all intermediary proxies/caches ?
18:12 ingsoc and i am still fuzzy abotu the effect of QS
18:12 ingsoc (quesry strings)
18:13 fumanchu intermediaries, too. one of the great things about HTTP is that there generally isn't a difference unless you explicitly ask for it
18:17 ingsoc fumanchu: is there any way of requesting a url and cache busting to get the resource from source no matter what ?
18:17 fumanchu yes, that's easy. Just send a "Cache-Control: no-cache" request header
18:18 fumanchu HTTP caching is designed to let the server *advise* the client on cache lifetime, not *demand*
18:18 fumanchu (the HTTP specs use the term "origin server" instead of "source")
18:19 fumanchu (yet another great thing about HTTP caching that in-app Memcache etc always end up reinventing)
18:24 DrCode joined #rest
18:25 ingsoc I think caching is gonna be a big win for things like, api/fleet_mileage_report/yyyy/mm  this would be quite computationally intensive calculating the miles driven by each vehicle in the fleet in the selected month or it could be week.
18:25 ingsoc I was originally gonna cache these kinds of reports locally but as your answer on stack overflow suggests, a lot of the need for things like memcache could be made obsolete with intelligent use of caching infrastructure
18:27 ingsoc the main problem i have noticed is that JSON serialisation can eat up CPU resources and I am dealing with 100's/1000's records for each vehicle per day
18:28 orriols joined #rest
18:47 danizord joined #rest
18:51 whartung all serializaiton eats up CPU
20:12 mikehaas763 joined #rest
20:14 mikehaas763 Hi. How are most people handling the "soft" deletion of resources?
20:16 trygvis mikehaas763: it's not clear to me what you're really asking and what your issue is
20:17 DrCode joined #rest
20:24 whartung soft for who?
20:28 fumanchu joined #rest
20:29 mikehaas763 soft deleting a resource, the deletion is basically a regular delete, but we have regulations where we need to keep the data around.
20:29 mikehaas763 DELETE  /res-a/1/res-b/2
20:30 mikehaas763 I suppose thinking more about it, it's still a DELETE for the client consuming the API
20:32 orriols joined #rest
20:42 whartung yes
20:43 whartung if you mean by soft delete, youre simply changing an internal status (i.e. the backing data remains, but is invalid for access), then from the client perspective, there's no difference, and DELETE is appropriate
20:43 whartung yea I work in healthcare, we can't delete anything :)
21:01 woky_ joined #rest
21:30 systmkor joined #rest
23:42 pdurbin whartung: can't delete anything... have you looked at http://datomic.com ?
23:54 gtramontina joined #rest

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

#rest on freenode has been logged here from May 2014 until end of July 2018 but logging has been suspended because the channel has been riddled with spam since August 2018 with no end in site. See the following blog posts about the problem:

Until the spam problem has been dealt with and logging can resume, please visit our wiki at https://trygvis.io/rest-wiki/

Thanks.