| Time |
S |
Nick |
Message |
| 01:13 |
|
|
fuzzyhorns joined #rest |
| 01:31 |
|
|
baweaver joined #rest |
| 03:27 |
|
|
fumanchu joined #rest |
| 03:43 |
|
|
talios joined #rest |
| 04:32 |
|
|
talios joined #rest |
| 05:21 |
|
|
itscaleb joined #rest |
| 05:27 |
|
|
itscaleb joined #rest |
| 05:28 |
|
|
itscaleb joined #rest |
| 05:40 |
|
|
jackeroo_marc joined #rest |
| 06:03 |
|
|
itscaleb left #rest |
| 06:34 |
|
|
itscaleb joined #rest |
| 06:38 |
|
|
rosstuck joined #rest |
| 07:13 |
|
|
timg___ joined #rest |
| 07:29 |
|
|
azr joined #rest |
| 08:19 |
|
|
timg___ joined #rest |
| 08:28 |
|
|
chthon joined #rest |
| 08:39 |
|
|
interop_madness joined #rest |
| 08:40 |
|
|
azr joined #rest |
| 08:56 |
|
|
azr joined #rest |
| 10:12 |
|
|
azr joined #rest |
| 10:32 |
|
|
timg___ joined #rest |
| 10:53 |
|
|
mezod joined #rest |
| 11:27 |
|
|
azr joined #rest |
| 11:28 |
|
|
timg___ joined #rest |
| 11:28 |
|
|
_ollie joined #rest |
| 11:58 |
|
|
timg___ joined #rest |
| 12:02 |
|
|
timg___ joined #rest |
| 12:32 |
|
|
_ollie joined #rest |
| 13:10 |
|
|
dEPy joined #rest |
| 13:22 |
|
|
_ollie joined #rest |
| 13:30 |
|
|
azr joined #rest |
| 13:43 |
|
|
chthon joined #rest |
| 14:13 |
|
|
pokEarl joined #rest |
| 14:13 |
|
|
pokEarl joined #rest |
| 14:14 |
|
|
pokEarl joined #rest |
| 14:14 |
|
|
pokEarl joined #rest |
| 14:27 |
|
|
_ollie joined #rest |
| 14:57 |
|
|
anth0ny_ joined #rest |
| 14:59 |
|
anth0ny_ |
Design question: I'm having a conversation w/ a coworker about how to design interactions with objects on our API. Let's say we have /cameras, each representing a real-world ip-camera. If we want to take a picture from that camera, would it make more sense to GET /cameras/{i}/take_picture or POST /images/?action=take_picture&id={i} ? |
| 15:00 |
|
anth0ny_ |
one of us is saying that POST makes more sense because you're creating a resource on the DB (take_picture) saves the image, the other says taht GET makes sense because it's an action on a camera and you're requesting to retrieve an image |
| 15:05 |
|
asdf` |
"GET makes sense because it's an action on a camera" <-- that's why GET doesn't make sense, actually ;) |
| 15:07 |
|
asdf` |
it'd be a GET that isn't idempotent so you can't really mash f5 on it; it's also not cacheable |
| 15:09 |
|
anth0ny_ |
asdf`: is idempotency a requirement for GET? If I wanted to get the reading off of a temperature sensor behind a rest api, wouldn't it be the most natural to GET that reading? |
| 15:09 |
|
trygvis |
you're not changing the state of the resource if you GET /temperature |
| 15:10 |
|
sfisque |
i would argue that this is outside REST because it's actually an RPC and not an operation on a resource |
| 15:10 |
|
anth0ny_ |
but, if I told you that the /temperature reading stored its value in the DB at every request, would that then no longer make sense to be a GET? |
| 15:10 |
|
|
timg___ joined #rest |
| 15:11 |
|
sfisque |
asking a resource to perform an operation does not sound "rest-ish" |
| 15:11 |
|
asdf` |
it kinda depends; if each request were to create a " |
| 15:11 |
|
asdf` |
it kinda depends; if each request were to create a "temperature reading resource", then that's not a good idea for GET; like, if you later wanted to retrieve /readings/42 |
| 15:12 |
|
* asdf` |
misplaced quotes above: "temperature reading" resource |
| 15:12 |
|
anth0ny_ |
asdf`: my hangup with POST is that I typically think of POST creating the resource from the data provided within the POST, not as an instruction to get the data elswhare |
| 15:13 |
|
sfisque |
anth0ny_ that is why i'm saying it's outside of REST. what you describe is RPC |
| 15:13 |
|
asdf` |
yep, that's also what sfisque says |
| 15:14 |
|
sfisque |
you have to keep in mind that REST does not solve everything nor is it "ubiquitous". it is "just another tool in the toolbox" for solving design questions |
| 15:14 |
|
sfisque |
there is no heresy if you have RPC and REST side by side in your fabric |
| 15:14 |
|
anth0ny_ |
sfisque: do you have any advice regarding meshing RPC with REST? |
| 15:15 |
|
sfisque |
basically common sense. if you're exposing "functionaliity" make it RPC. if you're exposing resources that can be "acted on", make them REST |
| 15:16 |
|
sfisque |
e.g. "start the background workflow processes" == RPC , "update my account with this metadata fragment" == REST |
| 15:17 |
|
sfisque |
gotta bounce. ttyl |
| 15:17 |
|
anth0ny_ |
sfisque: thanks for your opinion |
| 15:23 |
|
|
rosstuck joined #rest |
| 15:24 |
|
fumanchu |
in REST terms, you're advancing the state of your client's application by taking another picture. The question is, what state do you transfer to accomplish that? |
| 15:25 |
|
fumanchu |
a common pattern for this is to have an images/ collection which acts as a sink and several cameras/{i}/ resources which are sources |
| 15:25 |
|
anth0ny_ |
fumanchu: in that regard, yes it's an Image resource |
| 15:26 |
|
anth0ny_ |
fumanchu: i don't quite understand the 'sink' and 'sources' terminology |
| 15:26 |
|
fumanchu |
you have a target and several sources |
| 15:26 |
|
fumanchu |
the operation is to get a Thing from a source and add it as an item to the target collection |
| 15:27 |
|
anth0ny_ |
right, so the source is Camera and the target collection is Images, right? |
| 15:27 |
|
fumanchu |
right |
| 15:27 |
|
fumanchu |
think of images/ as a collection that can receive images from anywhere...you could POST a GIF from your hard drive to it |
| 15:27 |
|
fumanchu |
classic REST |
| 15:28 |
|
anth0ny_ |
absolutely, that part is clear |
| 15:28 |
|
fumanchu |
all you're doing is short-circuiting that a bit by saying, "actually, I don't want to GET the image myself and then POST it to you, you do that, and here's it's URL" |
| 15:28 |
|
anth0ny_ |
just stumbling about how to cleanly create resource B from source A |
| 15:29 |
|
anth0ny_ |
fumanchu: so what are you actually saying regarding whicih design is more clean? |
| 15:29 |
|
fumanchu |
POST images/ HTTP/1.1 |
| 15:29 |
|
fumanchu |
{"source": "cameras/3/current_view"} |
| 15:29 |
|
anth0ny_ |
hmm... interesting |
| 15:30 |
|
fumanchu |
that then allows you to extend "POST to images/" with other URL's or media types in the future |
| 15:30 |
|
anth0ny_ |
that's a pretty fun idea |
| 15:31 |
|
anth0ny_ |
and I can still do /cameras/3/current_view |
| 15:31 |
|
|
azr joined #rest |
| 15:31 |
|
anth0ny_ |
just to see what's up |
| 15:31 |
|
fumanchu |
right |
| 15:31 |
|
fumanchu |
(it also properly invalidates cached copies of the images/ collection so a subsequent GET would include a link to the new image) |
| 15:32 |
|
anth0ny_ |
fumanchu: can you expand what you mean by "properly invalidates cached copies"? what is properly/improperly? |
| 15:33 |
|
fumanchu |
if you added a new image to the collection by "GET cameras/3/current_view", then caches between your client and the server might still serve a stale copy of the images/ resource |
| 15:33 |
|
fumanchu |
it's easy to run into problems there where you add the image but then your client won't show it to you |
| 15:33 |
|
anth0ny_ |
okay, but a POST to /images tells a browser that its cache is stale? |
| 15:33 |
|
fumanchu |
because you're looking at a stale copy of the catalog of images |
| 15:34 |
|
fumanchu |
any POST to a URL tells caches to drop their stored copies |
| 15:34 |
|
anth0ny_ |
interesting, I didn't know that |
| 15:35 |
|
anth0ny_ |
cool, i think you've set us in the right direction fumanchu, thanks a lot |
| 15:35 |
|
fumanchu |
np |
| 15:35 |
|
anth0ny_ |
do you have any recommended resources regarding API design? |
| 15:35 |
|
anth0ny_ |
or is this just sage fumanchu wisdom here? |
| 15:35 |
|
fumanchu |
I wish I did :/ just hard-won experience |
| 15:36 |
|
fumanchu |
I have encapsulated a lot of it into a media type: https://bitbucket.org/fumanchu/shoji/src/tip/spec.txt |
| 15:36 |
|
anth0ny_ |
woah, awesome, will take a look |
| 15:40 |
|
fumanchu |
I would probably make images/ a Shoji Catalog. One idea would be to have it collect images rather than contain them, so rather than have links to e.g. images/23974928362/, it would link to cameras/3/2015-06-03T15:13:12.3982746/ |
| 15:40 |
|
anth0ny_ |
fumanchu: actually, one more question regarding caching, if we're doing GET /cameras/3/current_view, don't I run the risk of that being cached? Is that something I should just specify with the response header (tell browser not to cache it)? |
| 15:40 |
|
fumanchu |
correct, include no-cache response headers |
| 15:41 |
|
anth0ny_ |
fumanchu: is Shoji something that you came up with? I'm not familiar with it |
| 15:41 |
|
fumanchu |
(although at really high load you might want a 1-minute cache lifetime or what-have-you) |
| 15:41 |
|
fumanchu |
yes, it's my own. used it at a few companies now |
| 15:45 |
|
fumanchu |
some example API docs with Shoji: http://crunch-io.github.io/apidocs/#datasets |
| 16:32 |
|
|
azr joined #rest |
| 16:42 |
|
|
rosstuck joined #rest |
| 17:49 |
|
|
itscaleb joined #rest |
| 17:56 |
|
|
anth0ny joined #rest |
| 18:02 |
|
|
azr joined #rest |
| 18:06 |
|
|
Voyage joined #rest |
| 18:06 |
|
Voyage |
Hi |
| 18:06 |
|
Voyage |
Can rest return multiple objects like string, numbers, images? |
| 18:09 |
|
sfisque |
Voyage if it makes sense (aka return an "object" that has attributes of multiple types) |
| 18:09 |
|
sfisque |
{ name : "blah", age : "12", image : "[some binhex data]" } |
| 18:12 |
|
Voyage |
sfisque, bin /ex data or base 64 wont be effecient. |
| 18:12 |
|
Voyage |
to tell you the real story. I am passing list of objects from server to mobile app. Each object has one string, integer, image and video. |
| 18:14 |
|
whartung |
I'd return a MIME payload, myself if you're sending back images and video |
| 18:15 |
|
sfisque |
Voyage you asked a question and i answered it. you made no mention of efficiency. the answer is "yes". efficiency is left as an exercise for the reader :-D |
| 18:16 |
|
Voyage |
whartung, please explain? |
| 18:16 |
|
Voyage |
sfisque, so whats the solution? base64 is not efficient |
| 18:17 |
|
Voyage |
sfisque, i cant just send images and videos or other files like .exe in json |
| 18:18 |
|
sfisque |
depends on the problem. if your images are small, base64, compressed base64, or some other bin-text conversion is fine. if you're talking huge video or images, you might want to include links to them (separate linked resources) or as whartung points out, use a multi-part return |
| 18:18 |
|
whartung |
Multupart MIME is a standard encoding that lets you return multiple parts (thus the "multipart" part). Each of those parts have their own mime type and can include binary data |
| 18:18 |
|
Voyage |
hm |
| 18:19 |
|
Voyage |
lets say, I have a java object in a class that has a string, int, image, video. I understood that I can send it as zip formate but how the other party (mobile) will read it and expand it to those objects back again? |
| 18:19 |
|
whartung |
who cares how they do it? |
| 18:19 |
|
sfisque |
^^^ truth |
| 18:19 |
|
whartung |
it can be done... |
| 18:19 |
|
Voyage |
whartung, I got it. so like we post multi part, we can also receive multipart |
| 18:19 |
|
whartung |
of course |
| 18:19 |
|
sfisque |
analagous to parsing an email with attachments. same process |
| 18:19 |
|
whartung |
I mean, a ZIP file is perfectly valid -- it's essentially the same thing with "free" compression |
| 18:19 |
|
Voyage |
how will the mobile app be able to parse it? if its zipped java object |
| 18:20 |
|
sfisque |
you get to decide |
| 18:20 |
|
whartung |
they implement the "unzip" algorithms and parse the stream |
| 18:20 |
|
sfisque |
java can serialize to any format you want (it's pluggable) |
| 18:20 |
|
whartung |
yea, Ideally you're not sending down a serialized java object using java's internal serialization format. |
| 18:20 |
|
Voyage |
but a serialized java object can only be read by a java app |
| 18:20 |
|
sfisque |
negative |
| 18:21 |
|
sfisque |
java can serialize to xml off the shelf, and you can plug in any impl you want |
| 18:21 |
|
Voyage |
hm |
| 18:21 |
|
sfisque |
you can serialize to json, your own proprietary format, whatever |
| 18:21 |
|
whartung |
or you can force the poor suckers reading this to implement Javas internal serialization format. |
| 18:21 |
|
sfisque |
ROFL |
| 18:21 |
|
sfisque |
here's my api… suck it!!! |
| 18:21 |
|
sfisque |
:P |
| 18:22 |
|
Voyage |
serialization is just convering java ojbect into string/text or any other formate. I guess the inteface 'serializable' if implemented, implicitily converts to some text fomrat? |
| 18:22 |
|
sfisque |
Externalizable |
| 18:22 |
|
sfisque |
searchbot google javadoc Externalizable |
| 18:22 |
|
searchbot |
sfisque: Externalizable (Java Platform SE 7 ) - Oracle Documentation: <http://docs.oracle.com/javase/7/docs/api/java/io/Externalizable.html>; Externalizable (Codename One API): <https://www.codenameone.com/javadoc/com/codename1/io/Externalizable.html>; SparkFlumeEvent (Spark 1.4.0 JavaDoc): <http://spark.apache.org/docs/1.4.0/api/java/org/apache/spark/streaming/flume/SparkFlumeEvent.html>; LockOutFlag (3 more messages) |
| 18:22 |
|
Voyage |
sfisque, ok, If I serialize image to json via Java serialization, will that be effecient in contrast to base 64 encoding)? |
| 18:23 |
|
sfisque |
irrational question. if you're serializing to json you still have to rationalize the binary data to some "text" format |
| 18:23 |
|
whartung |
you should do the work and find an "appropriate" format for both you and your client. |
| 18:23 |
|
sfisque |
"12" != 12 |
| 18:24 |
|
Voyage |
sfisque, and still it will introduce inefficency? |
| 18:24 |
|
sfisque |
don't care |
| 18:24 |
|
sfisque |
it's not my api. you gotta figure out that part |
| 18:24 |
|
Voyage |
dont care? mobile apps do care about network usage |
| 18:24 |
|
sfisque |
i wasn't clear. "I" don't care. you care, and you need to solve that |
| 18:24 |
|
Voyage |
sfisque, ya sure, just asking the pros and cons. I surely will be the one who will code it |
| 18:24 |
|
Voyage |
sfisque, thanks for the help at this far. |
| 18:25 |
|
whartung |
you should be sending binary payloads for your large objects |
| 18:25 |
|
sfisque |
searchbot google image string encoding format efficient java |
| 18:25 |
|
whartung |
and mobile cares more about latency than bandwidth |
| 18:25 |
|
Voyage |
whartung, hm |
| 18:25 |
|
searchbot |
sfisque: How efficient is the encoding/decoding algorithm of BASE64 class in ...: <http://stackoverflow.com/questions/6355704/how-efficient-is-the-encoding-decoding-algorithm-of-base64-class-in-java>; Binary Data in JSON String. Something better than Base64 - Stack ...: <http://stackoverflow.com/questions/1443158/binary-data-in-json-string-something-better-than-base64>; What is the fastest Java library (3 more messages) |
| 18:26 |
|
whartung |
because images and videos are ALREADY compressed using standard algorithms (png, mpeg, etc.) so they're "as efficient as they're going to get" |
| 18:26 |
|
whartung |
(I assume the videos are properly codec'd already...) |
| 18:26 |
|
whartung |
if you send 4K video to my iphone 4S, I'll have paid assasins hunt you down |
| 18:27 |
|
sfisque |
i still have my grandfathered unlimited plan, so you can send them to me, for the time being… as long as they're good :P |
| 18:27 |
|
whartung |
they still throttle you |
| 18:27 |
|
whartung |
I have that too... |
| 18:27 |
|
sfisque |
yah, i know… i know... |
| 18:27 |
|
Voyage |
whartung, hm. |
| 18:27 |
|
whartung |
plus I have wifi turned off on my phone -- I pretty much always use the network |
| 18:29 |
|
Voyage |
whartung, what are your views for this (too many requests). If I include urls of images and videos and send them separately (each). and just send json text data in bulk (having those links and other strings). Will that introudce tooooo many request issue in a mobile device ? vs one data zip file having it all? |
| 18:32 |
|
Voyage |
hm generally speaking. Too man requests kills the mobile and its network? introduce latency issues etc? |
| 18:32 |
|
whartung |
yes |
| 18:33 |
|
Voyage |
If its not a big issue, I would go with the url based image resource |
| 18:33 |
|
Voyage |
oh |
| 18:33 |
|
Voyage |
but I guess a mobile device wont be able to see too many images at the same time in a screen. So will load async on scrolling of screen |
| 18:34 |
|
Voyage |
will use url for each image |
| 18:34 |
|
Voyage |
will store file path for each image in the database |
| 18:34 |
|
sfisque |
or offer both in your api. let them either "get it all" or "get anemic and fluff as needed" |
| 18:34 |
|
Voyage |
will use rest server to do the math, get correct path of file from db and sent the file to user via API |
| 18:35 |
|
Voyage |
sfisque, well, i am making the mobile app AND the REST server |
| 18:35 |
|
Voyage |
:) |
| 18:35 |
|
Voyage |
there is no 'them' |
| 18:35 |
|
sfisque |
so a tablet on wifi can do a "fat fetch" and let constrained clients do "anemic fetch" |
| 18:35 |
|
Voyage |
hm |
| 18:35 |
|
Voyage |
too much coding for small task. but i see it inevitable |
| 18:35 |
|
sfisque |
something to consider. worse case, stub it out and back fill as needed |
| 18:36 |
|
Voyage |
ok. thanks for being informative |
| 18:36 |
|
Voyage |
sfisque, whartung ^ |
| 18:36 |
|
|
Voyage left #rest |
| 18:47 |
|
|
_ollie joined #rest |
| 19:24 |
|
|
mgomezch joined #rest |
| 19:33 |
|
|
azr joined #rest |
| 19:47 |
|
|
saml joined #rest |
| 19:52 |
|
|
_ollie joined #rest |
| 19:59 |
|
|
_ollie joined #rest |
| 20:02 |
|
|
_ollie joined #rest |
| 20:06 |
|
|
cvander joined #rest |
| 20:33 |
|
|
_ollie joined #rest |
| 20:55 |
|
|
azr joined #rest |
| 21:54 |
|
|
fuzzyhorns joined #rest |
| 22:24 |
|
|
talios joined #rest |
| 22:30 |
|
|
_ollie joined #rest |
| 22:32 |
|
|
mezod_ joined #rest |
| 23:09 |
|
|
azr joined #rest |
| 23:29 |
|
|
fuzzyhorns joined #rest |
| 23:32 |
|
|
saml joined #rest |
| 23:37 |
|
|
_ollie joined #rest |
