greptilian logo

IRC log for #rest, 2018-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
04:21 wsieroci joined #rest
04:44 wsieroci joined #rest
12:22 Haudegen joined #rest
13:55 interop_madness joined #rest
13:55 interop_madness joined #rest
17:11 wsieroci joined #rest
18:00 Guest87913 joined #rest
18:29 whartung joined #rest
23:34 ModusPwnens joined #rest
23:37 ModusPwnens I have an interesting restful design problem. I have the following APIS: 1. Append data to an audio stream (PUT /v1/audio/{id}/stream) 2. Get the entire audio data (GET /v1/audio. No ID because the client passes a token that tells us what item to fetch)
23:38 ModusPwnens However, now we need to support streaming GETs. the previous GET API may have some audio transformations applied before returning whereas this streaming get will not. How can I represent that restfully? I'd like to represent it as a subresource, but since we don't have an ID it would look like /v1/audio/stream, which seems odd
23:38 whartung Well, in theory, the PUT replaces then entire resource, rather than appending to it.
23:39 whartung how are the transformations manifested?
23:39 ModusPwnens ah sorry, it's a post, not a put
23:39 ModusPwnens what do you mean by manifested?
23:40 whartung well, let’s take a contived example.
23:40 whartung a photo
23:40 whartung your reource is “the photograph"
23:41 whartung but you can have it in color, and in black and white. Two representations of the same resource.
23:41 whartung Make sense?
23:41 ModusPwnens Yes, that makes sense.
23:41 whartung So, there in theory needs to be a way to distinguish which of those representations you will get.
23:41 ModusPwnens ah, in this case, the transformations are always applied
23:42 ModusPwnens except for streaming
23:42 whartung now, one way could be with the Content-Type header: image/jpeg; b&w
23:43 whartung right, see? it’s not the same representation.
23:43 whartung how are you going to do the streaming, what does that even mean in this case? How does “streaming” differ from “suck the entire thing down”?
23:45 whartung (sorry I meant the Accept header above, not content-type)
23:48 ModusPwnens my point is that i don't want to demux on the transformations because i don't want clients to be able to select certain transformations. Those transformations are required to happen for audio compatibility reasons that i can't really get into. However, clients can choose if they want the response streamed or not
23:49 whartung well, that’s not my question though. Don’t really care what the client can and can’t ask for. My question is how is “streaming” different from any other request, other than the transofrmations not being applied?
23:49 whartung what media types are being used?
23:49 whartung and what is the client?
23:49 ModusPwnens As far as streaming, the difference is that when you make a request to the non-streaming API, it will fetch everything in memory and then immediately return it. For streamed responses, it will fetch everything available so far and return it, while returning new information as soon as its available
23:50 ModusPwnens as an example, you can call the streaming get while the underlying audio is still being uploaded, but you cannot call the regular GET when that it's still being uploaded
23:51 whartung so, as a client, when I request the resrouce, in “normal” mode the request will block until its fully realized on the server, and then shipped down, while the streaming version will, in theory, “respond immediataely” but, perhaps, then “stall” if by  chance the client can request faster than the server can provide?
23:51 whartung but in the end, if I just do “curl http://host.com/audiothing”, I’ll end up with the whole thing either way, right?
23:54 ModusPwnens yeah, pretty much.
23:54 ModusPwnens except for extra transformations that may have been done on the non-streaming API
23:55 whartung right
23:55 whartung what content type are you using?
23:56 ModusPwnens application_octet_stream at the moment
23:57 whartung well you could add parameters to the Accept header: Accept: application/octet_stream; stream=yes
23:57 whartung you could also perhaps pass in an X-Stream token to the Content-Encodiing header.
23:57 whartung those are just applied to the same reosurce
23:58 whartung sorry, “Content-Transfer-Encoding"
23:59 whartung but I really think the Accept header is a better fit
23:59 ModusPwnens So just have the same API and branch behaviour based on the value of that header?
23:59 whartung sure

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