| Time |
S |
Nick |
Message |
| 01:11 |
|
|
Guest45613 joined #rest |
| 01:40 |
|
|
fuzzyhorns joined #rest |
| 02:59 |
|
|
fuzzyhorns joined #rest |
| 14:37 |
|
|
tbsf joined #rest |
| 14:38 |
|
|
tbsf joined #rest |
| 15:17 |
|
|
tbsf joined #rest |
| 15:22 |
|
|
tbsf joined #rest |
| 15:33 |
|
|
tbsf joined #rest |
| 16:37 |
|
|
tbsf joined #rest |
| 17:02 |
|
|
d4rklit3 joined #rest |
| 17:28 |
|
|
wsieroci joined #rest |
| 17:48 |
|
|
TMM joined #rest |
| 17:48 |
|
TMM |
hello |
| 17:48 |
|
TMM |
I'm designing a restful API and I was wondering if there is a best practice for optionally asynchronous operations |
| 17:48 |
|
TMM |
what I want to do is a have a default timeout for operations after which they automatically turn asynchronous |
| 17:49 |
|
TMM |
(unless requested through a header to have that not happen) |
| 17:49 |
|
TMM |
Is that a good idea? If so, is there a standard way of doing this? |
| 17:50 |
|
whartung |
why not simply make them all async? why have a time out at all? Are these fire and forget, or are there call backs involved? |
| 17:51 |
|
TMM |
primary for client authors, if a request completes in say < 200ms it'll save some resources to have to do a call again to retrieve the new resource |
| 17:51 |
|
TMM |
but a cli client may just want to sit there and wait |
| 17:52 |
|
asdf |
danger is, lazy implementors will just keep piling out longer timeouts instead of ever getting around to using the async api :) |
| 17:53 |
|
TMM |
that's no worse than not having it at all though, right? |
| 17:53 |
|
asdf |
i mean, it's pretty unusual i suppose, but the idea isn't super revolting (to me); it's just an optimization |
| 17:54 |
|
TMM |
I guess the alternative would be to have a field in all my resources that have a completion percentage or flag in it |
| 17:54 |
|
asdf |
normally all the operations are "asynchronous" - you create a resource, and sometime later you fetch its state again to see if it changed |
| 17:54 |
|
TMM |
but that seems extremely unrestful |
| 17:54 |
|
whartung |
I think it’s pretty awful - you as a consumer have no idea when “all of a sudden” you have to start asking for results. |
| 17:54 |
|
TMM |
due to the nature of the backend though some requests may take minutes to complete |
| 17:54 |
|
TMM |
For a web client that's just awful |
| 17:55 |
|
TMM |
but that same request *may* only take a couple of milliseconds |
| 17:56 |
|
whartung |
the problem is the client doesn’t “know” which is the case, and, worse, the behavior changes for reasons out of the clients control |
| 17:56 |
|
whartung |
so the client has to do all of the work, ALL THE TIME, to handle the ASYNC processing “just in case” |
| 17:56 |
|
TMM |
the server also doesn't really know until it's 'too late' |
| 17:57 |
|
TMM |
OK, so you think having ONLY async is better? |
| 17:57 |
|
TMM |
I really can't not have async requests |
| 17:57 |
|
TMM |
I can always know the resource url of the created resource though |
| 17:58 |
|
TMM |
so I guess I can just always respond with the new url and have that url have some way of determining the state of each resource |
| 17:58 |
|
TMM |
I don't know how 'resty' that is though |
| 18:00 |
|
|
wsieroci joined #rest |
| 18:00 |
|
TMM |
maybe I should ask this question a little different, I appear to talking in solutions-I-came-up-with |
| 18:01 |
|
TMM |
I hate it when people do that :P |
| 18:01 |
|
TMM |
How would you guys design this? |
| 18:21 |
|
asdf |
i mean, it's not rare to create a resource and start (short) polling it to see if it changed |
| 18:21 |
|
asdf |
really, i think if there needs to be some optimization, i'd have the server do it; ie. if it knows that it'll only take 100ms to make a full response, block for 100ms |
| 18:22 |
|
asdf |
not sure if it's that useful to let the client choose |
| 18:23 |
|
asdf |
if it's very critical for performance that the client decides what happens, then eh, you gotta do what you gotta do |
| 18:25 |
|
whartung |
how would we design what? You haven’t mentioned the use case |
| 18:29 |
|
TMM |
whartung, a restful api where the time for a resource to be fully ready can sometimes be very long |
| 18:30 |
|
TMM |
with a HTML client that can't just timeout |
| 18:30 |
|
whartung |
there’s two ways to do that. |
| 18:32 |
|
whartung |
One is you can have an “incomplete” resource, that when the client GETs it, it can introspect it and “see” it’s not quite ready, and can then poll waiting for it to fill. This way the resource is “always there”, but the contents and, perhaps, semantics change over time. |
| 18:32 |
|
whartung |
Similarly if that’s not acceptable, then instead you have a status resource, that operates similary, but has the semantics of a status resrouce rhather than the real resource. |
| 18:33 |
|
whartung |
then that is polled. |
| 18:33 |
|
whartung |
Either way, that URL is what is returned by the POST |
| 18:33 |
|
TMM |
hmm, I guess for all of my resources something that is pending can actually be used 'as normal' for almost all purposes |
| 18:34 |
|
whartung |
many system have the idea of a “lite” resource vs a “heavy” resource. same resource, different content type, one is a summary or subset of the other. |
| 18:35 |
|
TMM |
except for some operations that wouldn't make sense, I guess I can return a 449? |
| 18:35 |
|
whartung |
in the case with the “pending” resource, your client is going to have to actively poll. This is similar to the ASYNC problem. That means that it never knows if its initial request will be successful. |
| 18:36 |
|
whartung |
with the status resrouce, then the client is “always poling” before it gets ther eal resource. It’s seems a minor difference. but the semantics are different |
| 18:36 |
|
TMM |
yeah, I understand |
| 18:37 |
|
TMM |
I guess my server can simply 'guarantee' that if a resource is accepted that it will eventually fill |
| 18:37 |
|
TMM |
it can pretty much do that |
| 18:37 |
|
whartung |
really depends on how important the “full” resource is |
| 18:38 |
|
TMM |
Well, you create the resource for use outside of the api |
| 18:38 |
|
whartung |
well then I would do the status thing |
| 18:38 |
|
TMM |
but inside the api you use it to set access rights etc on it, you can do that on an incomplete resource |
| 18:38 |
|
whartung |
becase the “real” resource consumer doesn’t care about all this, it just wants the end result. the mechanations are unrelated. |
| 18:39 |
|
whartung |
so for the actual end user of the resrouce, it’s probably only interested in the full and complete resource |
| 18:39 |
|
TMM |
yeah, but I can see people wanting to set up their resources' access rights after creation, but before it is fully ready |
| 18:39 |
|
whartung |
sure |
| 18:45 |
|
TMM |
I'll just add some fields to resources that give their extra status |
| 18:45 |
|
TMM |
if resource creation fails due to the remote site just disappearing i need to explain that somehow anyway |
| 18:45 |
|
TMM |
and people may not want to sit there and wait for it regardless |
| 18:45 |
|
TMM |
thanks for the input |
| 18:45 |
|
whartung |
yw |
| 18:46 |
|
whartung |
let us know what works for you |
| 20:04 |
|
|
wsieroci joined #rest |
| 21:47 |
|
|
tbsf joined #rest |
| 21:57 |
|
|
tbsf_ joined #rest |
| 22:26 |
|
|
Haudegen joined #rest |
| 22:31 |
|
|
fuzzyhorns joined #rest |
| 23:23 |
|
TMM |
I was just reading this article on wikipedia: https://en.wikipedia.org/wiki/HATEOAS |
| 23:23 |
|
|
tbsf joined #rest |
| 23:23 |
|
TMM |
I kind of like the idea, but I'm somewhat puzzled about the example |
| 23:24 |
|
TMM |
how would a client know how to deposit just with the link? Is it a POST? a PUT? |
| 23:24 |
|
TMM |
Does this actually work in practice? |
| 23:24 |
|
whartung |
the person who write the client reads the documentation on the interface and the media types involved. |
| 23:24 |
|
asdf |
for example, see collection+json: http://amundsen.com/media-types/collection/ |
| 23:25 |
|
asdf |
json-ld is a pretty popular one, too |
| 23:25 |
|
whartung |
Note this key phrase: However, Collection+JSON defines both the format and the semantics in a single media type. |
| 23:26 |
|
TMM |
json-ld? |
| 23:26 |
|
whartung |
In essence the media type more than not should describe much of what you need to know as a client developer. |
| 23:26 |
|
TMM |
is using something like collection+json actually worth it? |
| 23:27 |
|
asdf |
Fielding says it is, for services that live for many years, and are accessed by many client writers |
| 23:27 |
|
whartung |
The benefit of HATEOAS is for apps with long term, wide spread and diverse clients. |
| 23:27 |
|
asdf |
then, having standardized stuff helps |
| 23:28 |
|
TMM |
ok, I was thinking of using this: http://jsonapi.org/ |
| 23:28 |
|
asdf |
if it is useful to you, nobody but you can say ;) |
| 23:28 |
|
TMM |
well, I do hope this software will get third party clients |
| 23:31 |
|
TMM |
I guess if I can use something that would completely do away with the need for separate api docs that would be nice |
| 23:31 |
|
TMM |
but if it still needs api docs would having to look in two places really be better? |
| 23:31 |
|
TMM |
I'm looking to be convinced btw :) I'm not trying to be smarter than the internets or anything |
| 23:31 |
|
whartung |
thats impossible save for the most trivial apps |
| 23:32 |
|
TMM |
I guess so |
| 23:34 |
|
whartung |
applications of any depth have semantics much richer than can be conveyed simply trhough payload syntax and the few HTTP verbs. |
| 23:34 |
|
TMM |
have you guys used any of these techniques? |
| 23:35 |
|
whartung |
the nice thing about HATEOAS is that your app can be more flexible and agile, as the payloads present the navigation that the clients should use to navigate state and workflow. It also can better support in place versioning and such. |
| 23:37 |
|
whartung |
A really smart guy wrote this up on SO: http://stackoverflow.com/questions/20335967/how-useful-important-is-rest-hateoas-maturity-level-3/20336307#20336307 |
| 23:41 |
|
TMM |
thanks |
| 23:41 |
|
TMM |
I'll digest :) |
