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