greptilian logo

IRC log for #rest, 2017-03-13

#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
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 :)

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