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