| Time |
S |
Nick |
Message |
| 00:00 |
|
travelr |
sfisque: you mentioned some things don't map to REST so I thought it'd be curious to learn more what doesn't map and why |
| 00:00 |
|
sfisque |
by complaint from experience has been with systems that involve a high fidelity of business rules, where the concept of "this object resides at that node" really does not map well (Master Data Managers are big culprits of this) have fallen prey to the "lets do REST" crusade. the results are less than "fun". rest is an awesome pathway to the semantic web, but it does not solve everything, nor do all problems map well to it |
| 00:01 |
|
sfisque |
***my complaint |
| 00:01 |
|
sfisque |
but that's by definition. endpoints resolve to resources, not functionality |
| 00:01 |
|
sfisque |
and not all systems map well to that |
| 00:01 |
|
travelr |
sfisque: can you please elaborate? a resource is like an entity and it should be somewhere right. |
| 00:03 |
|
sfisque |
right, but what if i have a system that does not expose resources but functionality (submit a payload and it disappears into the blackbox), e.g. a message bus. what does it mean to POST something or PUT something into a system that does not create a durable object at the requested URI? |
| 00:04 |
|
fumanchu |
a common example is any kind of streaming pipe-and-filter process where it doesn't make sense to ship intermediate products because they're too large to be buffered |
| 00:04 |
|
fumanchu |
Unix was invented for that problem |
| 00:04 |
|
sfisque |
aye |
| 00:05 |
|
sfisque |
some systems are based around a "durable". some systems are based around "function" |
| 00:05 |
|
sfisque |
durable maps very well to rest. function does not. |
| 00:05 |
|
travelr |
sfisque: well REST as CRUD is not the letter nor spirit of REST it's just "mainstream REST", which is more of a bad habit than a real standadd |
| 00:05 |
|
fumanchu |
Yahoo pipes notwithstanding ;) |
| 00:06 |
|
travelr |
sfisque: so if it was me I'd do what.. well, I already do: I'd submit the payload via POST into a URL like /action-name/ |
| 00:06 |
|
fumanchu |
which is not the REST style, but, that's totally ok if it fits your domain better |
| 00:07 |
|
travelr |
sfisque: I think the constraint isn't REST as much, the constraint is the mainstream limited interpretation of REST that popular kids want the other kids ot use |
| 00:07 |
|
travelr |
fumanchu: why not tho |
| 00:07 |
|
travelr |
fumanchu: I've thought long about it and I think it doens't conflict with anything in REST |
| 00:08 |
|
travelr |
fumanchu: a method call can be a resource as any |
| 00:08 |
|
travelr |
fumanchu: I have object resource which returns methods, and method resource which accepts data for processing |
| 00:08 |
|
sfisque |
i admit my understanding of fielding's paper is not 100%, but my understanding is a URI is supposed to represent a "durable" and not a functional |
| 00:08 |
|
sfisque |
what does it mean to PUT to a method? |
| 00:08 |
|
sfisque |
nonesensical |
| 00:09 |
|
travelr |
sfisque: what are the properties of "durable not functional"? |
| 00:09 |
|
sfisque |
durable == persistant data |
| 00:09 |
|
sfisque |
functional == executable code |
| 00:09 |
|
travelr |
sfisque: there's no requirement to support PUT on a method, but I'll tell you what it means in case you want to support it: it mean you create or overwrite a method on an object |
| 00:09 |
|
travelr |
sfisque: which is not totally out of possibility in a system |
| 00:10 |
|
sfisque |
i agree, but for most systems that would be a nightmare |
| 00:10 |
|
fumanchu |
the fact that it is possible does not mean it follow the style |
| 00:10 |
|
sfisque |
osgi would open that avenue up |
| 00:10 |
|
sfisque |
agreed fumanchu |
| 00:10 |
|
travelr |
sfisque: it wouldn't be because you don't have to support it blindly on everything. It can be supported for a set of dynamic objects if you have proper auth |
| 00:11 |
|
travelr |
I don't know - how do I violate the style. |
| 00:11 |
|
travelr |
I don't think I do. |
| 00:11 |
|
fumanchu |
by hiding the semantics of the message behind POST |
| 00:12 |
|
fumanchu |
you're not advancing state in a way that is visible to the client or to intermediaries |
| 00:12 |
|
fumanchu |
(like caches) |
| 00:12 |
|
travelr |
fumanchu: I'm not hiding it. |
| 00:12 |
|
travelr |
fumanchu: intermediaries can't see through HTTPS anyway |
| 00:12 |
|
fumanchu |
your browser cache is an intermediary |
| 00:13 |
|
travelr |
fumanchu: it's not because a client can intelligently invoke it and cache what it needs to cache |
| 00:13 |
|
fumanchu |
? |
| 00:13 |
|
travelr |
fumanchu: it's pretty much a requirement for apps that support offline mode |
| 00:14 |
|
fumanchu |
offline data is not an HTTP cache |
| 00:14 |
|
travelr |
HTTP cache is offline data. |
| 00:14 |
|
fumanchu |
that's not what it was designed for |
| 00:14 |
|
fumanchu |
even if you use it that way |
| 00:15 |
|
sfisque |
gotta bounce |
| 00:15 |
|
* sfisque |
goes dark |
| 00:15 |
|
travelr |
fumanchu: when I submit through POST the action is not cacheable to begin with, so this conversation is kind of pointless. If I want cacheable I *do allow GET* and head |
| 00:15 |
|
travelr |
So HTTP cache is not an issue, but not that much of a necessity either |
| 00:16 |
|
fumanchu |
and since cache is a constraint of the REST style, you're not following it. but ok, you don't have to. |
| 00:16 |
|
fumanchu |
you're not "in conflict" with it, you're just doing something else |
| 00:16 |
|
travelr |
Well not something else, I still support GET requests on nullipotent methods. |
| 00:17 |
|
travelr |
Which is precisely aligned with REST |
| 00:17 |
|
fumanchu |
that's like saying your skyscraper is Gothic because it has a heavy front door |
| 00:18 |
|
travelr |
fumanchu: I don't understand skyscrapers, but I understand REST :P |
| 00:18 |
|
fumanchu |
I disagree, but I can see you won't be convinced |
| 00:18 |
|
* fumanchu |
goes back to things that can be improved |
| 00:41 |
|
pdurbin |
whartung: I'd still love a little SP (OpenSAML) code: http://irclog.greptilian.com/rest/2015-04-28#i_111460 :) |
| 01:24 |
|
|
fuzzyhorns joined #rest |
| 01:26 |
|
fuzzyhorns |
sorry another set of dumb questions :x |
| 01:26 |
|
fuzzyhorns |
http request can only send back single file, and that file corresponds to a single hypermedia "document", yes? |
| 01:41 |
|
|
wsiqueir joined #rest |
| 01:43 |
|
fuzzyhorns |
but if i want to obey hateoas for a mobile client, does that mean the first hypermedia document i send is essentially the entire map of application state transitions possible? |
| 01:46 |
|
fuzzyhorns |
i guess what is tripping me up is the way rest is defined the server client interaction is central to each part of the control flow |
| 01:47 |
|
fuzzyhorns |
whereas really it seems i want to first send a big application state map to the client, then try to batch up as many resource state changes as possible into single almost "savepoint" requests to sync the local application to the persistance of it across the network |
| 01:47 |
|
fuzzyhorns |
im prob just missing stuff :c |
| 01:52 |
|
fuzzyhorns |
like i find examples like http://restcookbook.com/Basics/hateoas/ emphasize a request/response cycle |
| 02:17 |
|
fuzzyhorns |
maybe another way to put it is that on one side i feel pressure to normalize resources and keep them related via links (thus, separate documents?) but on the other hand i feel pressured to put everything in a single document due to latency |
| 02:34 |
|
fuzzyhorns |
http://blog.mugunthkumar.com/articles/restful-api-server-doing-it-the-right-way-part-2/ |
| 02:34 |
|
fuzzyhorns |
this ios developer says no to hypermedia |
| 02:34 |
|
fuzzyhorns |
well, hateoas i mean |
| 02:50 |
|
fuzzyhorns |
i feel like in general SPAs or mobile clients break some of these constraints: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven |
| 03:35 |
|
|
mamund joined #rest |
| 03:44 |
|
* mamund |
makes a rare appearance |
| 03:45 |
|
|
baweaver joined #rest |
| 04:01 |
|
|
sfisque joined #rest |
| 04:07 |
|
|
mamund joined #rest |
| 06:07 |
|
|
_ollie joined #rest |
| 06:27 |
|
trygvis |
mamund: hello! |
| 06:45 |
|
|
begriffs joined #rest |
| 07:07 |
|
|
Left_Turn joined #rest |
| 08:47 |
|
|
azer_ joined #rest |
| 09:05 |
|
|
quimrstorres joined #rest |
| 09:10 |
|
|
_ollie joined #rest |
| 09:19 |
|
|
Andre-B joined #rest |
| 09:37 |
|
|
quimrstorres joined #rest |
| 09:43 |
|
|
quimrstorres joined #rest |
| 10:10 |
|
pdurbin |
trygvis: should we ask mamund to add the new wiki to the topic? |
| 10:34 |
|
|
angular_mike_ joined #rest |
| 10:56 |
|
|
mezod joined #rest |
| 11:18 |
|
|
quimrstorres joined #rest |
| 11:33 |
|
trygvis |
pdurbin: I feel it is still lacking some content :) |
| 11:33 |
|
pdurbin |
yeah. no rush :) |
| 11:38 |
|
|
liamkeily joined #rest |
| 11:45 |
|
|
mezod joined #rest |
| 11:54 |
|
|
interop_home joined #rest |
| 11:54 |
|
|
interop_home joined #rest |
| 12:08 |
|
|
liamkeily joined #rest |
| 12:44 |
|
|
alxbl joined #rest |
| 13:31 |
|
|
nkoza joined #rest |
| 13:48 |
|
|
wsiqueir joined #rest |
| 14:00 |
|
trygvis |
I think this is good stuff: http://blog.schema.org/2015/05/schema.html |
| 14:00 |
|
trygvis |
in particular for "the web", probably not very relevant for REST |
| 14:00 |
|
|
fuzzyhorns1 joined #rest |
| 14:01 |
|
pdurbin |
yeah, I see a lot of great schema.org stuff by following https://plus.google.com/+DanScottCAN/posts |
| 14:04 |
|
trygvis |
cool |
| 14:07 |
|
|
fumanchu_ joined #rest |
| 14:16 |
|
fuzzyhorns1 |
ive seen a lot of doubt that mobile development can make us of HATEOAS and even going so far as to say its now gonna become obsolete |
| 14:20 |
|
trygvis |
really? I see mobile apps as the perfect user of HATEOAS and REST as the system need to support a large number of clients (caching becomes important), a diverse set of use cases supported (many apps against the same company) and many versions deployed concurrently |
| 14:20 |
|
fuzzyhorns1 |
trygvis: have you seen http://blog.mugunthkumar.com/articles/restful-api-server-doing-it-the-right-way-part-2/ ? |
| 14:21 |
|
fuzzyhorns1 |
i think the general form of the arguments seem to be: 1. hateoas suggests lots of request/response cycles and ownership of application state primarily by the server and 2. hypermedia formats arent as well supported on native devices (idk about this one) |
| 14:22 |
|
_ollie |
I fail to see the "argument" in these two opinions |
| 14:23 |
|
_ollie |
2. if you stay with JSON, what a client has to understand is where links are… that's a JSON Path expression |
| 14:23 |
|
fuzzyhorns1 |
json isnt hypermedia format |
| 14:23 |
|
fuzzyhorns1 |
so, sure :d |
| 14:23 |
|
fuzzyhorns1 |
it is a media format, but not a hypermedia format |
| 14:23 |
|
_ollie |
right… that's why i wrote "understand where links are" |
| 14:24 |
|
_ollie |
you don't even have to under stand HAL in its entirety to find links, that's my argument |
| 14:24 |
|
_ollie |
so "not well supported" is basically everything but an argument… |
| 14:24 |
|
fuzzyhorns1 |
to me the 2nd one is less strong because idk native apis at all |
| 14:24 |
|
_ollie |
1. lot's of requests… compared to what exactly? |
| 14:25 |
|
_ollie |
1. application logic on the server… ack, that's a feature. |
| 14:25 |
|
fuzzyhorns1 |
in mobile the tendency is one big request up front to load the app |
| 14:25 |
|
fuzzyhorns1 |
to me that's the big thing, _ollie |
| 14:25 |
|
_ollie |
so what prevents you from doing that with REST? |
| 14:25 |
|
fuzzyhorns1 |
i have several coworkers that really feel mobile development is basically using the "web" as a standardized vm where the entire app really lives on the client |
| 14:26 |
|
_ollie |
there's two types of people complaining about REST: those who complain about to many requests and those that complain about to big payloads… |
| 14:26 |
|
fuzzyhorns1 |
i dont really get the 2nd complaint of those, though ive seen it :d |
| 14:26 |
|
_ollie |
your filter bubble maybe? |
| 14:26 |
|
_ollie |
I guess there's a fundamental misconception here… |
| 14:27 |
|
fuzzyhorns1 |
sure, i am an embodied human, i do not perceive all opinions lol |
| 14:27 |
|
_ollie |
it's totally fine not to do rest for mobile. |
| 14:27 |
|
_ollie |
but |
| 14:27 |
|
fuzzyhorns1 |
to me, the evolvability of hateoas is the request/response cycle and ownership of application logic on the server |
| 14:27 |
|
fuzzyhorns1 |
but my coworkers that do mobile are very anti that, and just basically want huge blobs of json |
| 14:27 |
|
_ollie |
following REST gives you a set of traits that your application gets from following it… if you value those, follow REST, if you don't don't |
| 14:28 |
|
_ollie |
If you don't need evolability, if you don't need cacheability… don't do it… I'd argue mobile apps are a very good are where this is needed. |
| 14:28 |
|
fuzzyhorns1 |
"take it or leave it" sure |
| 14:29 |
|
fuzzyhorns1 |
no need to be a grump with me, btw, i am not some skeptic |
| 14:29 |
|
trygvis |
fuzzyhorns1: it still might be a good idea to give them big blobs of json as long as they discover it |
| 14:29 |
|
_ollie |
if you think about it… huge payloads basically undermine cachability… no cachability basically means more requests… so instead of a lot of small requests you now get a lot of big requests… |
| 14:29 |
|
trygvis |
but I'm sure they will argue for some sort of "change list" the next time the app starts so they don't have to download the big blob the next time the app starts |
| 14:29 |
|
fuzzyhorns1 |
sure, to my view it is somewhat of a misconception |
| 14:30 |
|
fuzzyhorns1 |
but if the goal is to traverse links (and those links were provided by self-descriptive messages from the server to stay current) |
| 14:30 |
|
trygvis |
several modern hypermedias allow embedding of resources so you can tunnel resources inside another resource |
| 14:30 |
|
fuzzyhorns1 |
that often suggests more requests |
| 14:30 |
|
fuzzyhorns1 |
trygvis: yeah so basically back to "give them a huge denormalized document" |
| 14:30 |
|
fuzzyhorns1 |
which is what kinda bums me out |
| 14:30 |
|
trygvis |
not really |
| 14:31 |
|
trygvis |
you can take those resources and inject them into your cache |
| 14:32 |
|
_ollie |
you mess up goal and means… the goal is never to traverse links… |
| 14:32 |
|
_ollie |
nobody win's a price for making three requests to finally find a resource where one hop would've been enough… |
| 14:32 |
|
_ollie |
traversing links is a means to an end… |
| 14:32 |
|
fuzzyhorns1 |
yes, thank you _ollie |
| 14:33 |
|
_ollie |
the point is: if the client is *generally hypermedia* enabled… you can detect those wasteful scenarios and change the server accordingly to optimize without touching the client… |
| 14:34 |
|
|
azr joined #rest |
| 14:34 |
|
fuzzyhorns1 |
_ollie: so, in one case you eagerly aggregate and send more application/resource state to send to the client so that it neednt make more requests? |
| 14:35 |
|
fuzzyhorns1 |
that's the thing that bugs me though, because then the client really owns the current state, and the sever is just a back up persistence layer it syncs to |
| 14:38 |
|
_ollie |
why does the client own the resource state? |
| 14:38 |
|
fuzzyhorns1 |
it is cacheing it locally and operating on it for future application and resource state changes, working independently, and then at certain "savepoints" batching the data to the server |
| 14:38 |
|
fuzzyhorns1 |
all to minimize requests |
| 14:39 |
|
fuzzyhorns1 |
(this is just what ive seen done, i am not advocating here) |
| 14:39 |
|
_ollie |
uless state is not on the server, it annot be seen by other clients |
| 14:39 |
|
_ollie |
thats my definition of own |
| 14:39 |
|
fuzzyhorns1 |
that is a fair definition |
| 14:41 |
|
_ollie |
CRUD over HTTP is not rest if that's what youre after |
| 14:41 |
|
fuzzyhorns1 |
for me it is not what im after |
| 14:42 |
|
fuzzyhorns1 |
but again, ime, that is what mobile wants |
| 14:42 |
|
_ollie |
says who? |
| 14:42 |
|
fuzzyhorns1 |
they do not want to allow flow control (to me hypermedia) to belong to the server |
| 14:42 |
|
fuzzyhorns1 |
says the mobile devs at my work :d |
| 14:43 |
|
_ollie |
so they've decided against rest for $reason… what's the point? |
| 14:43 |
|
fuzzyhorns1 |
hmm? |
| 14:43 |
|
fuzzyhorns1 |
do you mean what is their point? why did they decide against it? |
| 14:44 |
|
fuzzyhorns1 |
here i'll just quote one of them lol |
| 14:44 |
|
_ollie |
no? how does that decision make REST a good deciion for mobile or not? i don't get it |
| 14:44 |
|
fuzzyhorns1 |
tbh _ollie, i feel like youre just being obtuse and condescending with me, whereas what i want is enough context to validate or invalidate the views of my colleagues lol |
| 14:45 |
|
fuzzyhorns1 |
im not here to fight you dude |
| 14:45 |
|
fuzzyhorns1 |
"the problem with HATEOAS (which i do kind of like), especially in the context of mobile, is the network when writing a mobile app (a good mobile app) you have to assume that you pretty much can only occasionally get a connect to sync data with the server which means you need to be able to do most of your application’s work offline and can’t rely on the server to tell you what you can do next" |
| 14:46 |
|
_ollie |
thats so vague, it's not even funny… |
| 14:46 |
|
trygvis |
it's really not a big problem with letting the client being offline for a while and push changes later on, you just have to let design your rest application that way |
| 14:47 |
|
fuzzyhorns1 |
that is my impulse, trygvis |
| 14:47 |
|
trygvis |
if supporting batch updates/synchronization is important, design for it |
| 14:47 |
|
trygvis |
if conflict resolution is important, design for it |
| 14:47 |
|
_ollie |
i can browse the locllay cached version of a catalogue just fine, but guess what, if I want to check out my cart, i need to be onine, surprise surprise |
| 14:48 |
|
trygvis |
fuzzyhorns1: what does your app do?' |
| 14:49 |
|
fuzzyhorns1 |
trygvis: to me it is a more general tension i'm trying to articulate |
| 14:49 |
|
trygvis |
ok. you probably won't find many hypermedias that are geared towards the problems you face with mobile apps |
| 14:50 |
|
trygvis |
which is an issue because I think those would be useful for general machine-to-machine stuff |
| 14:51 |
|
fuzzyhorns1 |
trygvis: i want hypermedia (documents sent by the server) to drive application state, but in order to give the client a lot of latitude to work without the server responses, i need to give a large, eager map of potential application state. if i give all that up front, i now rely on the client app to figure out its state within the map |
| 14:51 |
|
fuzzyhorns1 |
trygvis: that is what i worry about, and my work place is going very "mobile first" whereas i think of myself as a rest api dude |
| 14:51 |
|
trygvis |
well, you have to think of the REST applications as a much more course grained appliation than what you do inside the mobile application |
| 14:52 |
|
fuzzyhorns1 |
i guess i am thinking, trygvis, that in mobile the "code on demand" constraint becomes primary |
| 14:52 |
|
trygvis |
like if the mobile app takes care of creating a bunch of new resources by pulling in lots of data and let the user go nuts, and then later on synchs to the server |
| 14:52 |
|
fuzzyhorns1 |
in that i give the client a lot of code to do application logic/business logic (versus presentation logic) |
| 14:52 |
|
trygvis |
the mobile app is all the fancy stuff of showing selectors and fancy search bars, and the rest application is just the part of taking the batches and persisting them |
| 14:53 |
|
trygvis |
for mobile stuff I would just drop code on demand and having the server drive the UI |
| 14:53 |
|
fuzzyhorns1 |
yeah, in which case, it seems like rest app just becomes a new persistence api |
| 14:53 |
|
trygvis |
it could drive some parts of the UI, depends on your app |
| 14:53 |
|
trygvis |
maybe it is, but certainly doesn't have to be |
| 14:54 |
|
fuzzyhorns1 |
to me, i would prefer the client be basically for presentation |
| 14:54 |
|
trygvis |
on example is creating invoices. that can be done on the phone and you need a lot of background data |
| 14:54 |
|
fuzzyhorns1 |
but from what i understand from mobile folks, the entirety of the app will really be theirs |
| 14:54 |
|
trygvis |
customers, product catalogs, address lists |
| 14:55 |
|
trygvis |
but the only thing the server needs to worry about is the actual creation of the invoice and what to do with it (like sending by email, mobile notifications, printer) |
| 14:55 |
|
fuzzyhorns1 |
in which case, is hypermedia the engine of application state? |
| 14:55 |
|
trygvis |
it's kind to explain how REST would work for you without knowing anything about their cases |
| 14:56 |
|
fuzzyhorns1 |
the application state is pretty much all managed on the client app, and hypermedia becomes the engine of persisting state |
| 14:56 |
|
trygvis |
yes, definitely. it's just that the operation is "create invoice" |
| 14:56 |
|
|
mezod joined #rest |
| 14:56 |
|
trygvis |
no, it doesn't |
| 14:56 |
|
trygvis |
it's just more course grained |
| 14:57 |
|
fuzzyhorns1 |
im saying it becomes so course grained that it basically falls back to being just a transport |
| 14:57 |
|
fuzzyhorns1 |
a more semantic transport |
| 14:57 |
|
fuzzyhorns1 |
but it is no longer the engine of "app" state |
| 14:58 |
|
trygvis |
creating an invoice is no simple thing, there are lots of options, both before and after the invoice is created. that is orchestrated/controlled by the server |
| 14:59 |
|
fuzzyhorns1 |
idk, to me then it just is like, then the server really is just a database, maybe a message publisher (to other subscribers interested in an event of one of its clients) |
| 15:00 |
|
fuzzyhorns1 |
it does, by increments, control the flow of the actual application |
| 15:00 |
|
fuzzyhorns1 |
it just manages its persitance :d |
| 15:00 |
|
fuzzyhorns1 |
god i can NOT spell that word right |
| 15:00 |
|
trygvis |
some people would call that flexibility :) |
| 15:03 |
|
trygvis |
fuzzyhorns1: anyway, it's hard to talk/explain/argue without being a bit more specific |
| 15:03 |
|
trygvis |
and now I'm going home from work! |
| 15:03 |
|
fuzzyhorns1 |
trygvis: i appreciate talking to you |
| 15:03 |
|
fuzzyhorns1 |
i will try to bring a more specific example at some point |
| 15:29 |
|
fumanchu_ |
aside: when REST talks about "application state" it means "where am I (user or agent) in the process I'm trying to pursue" not "what is the state of a set of resources" |
| 15:30 |
|
|
mezod joined #rest |
| 15:30 |
|
fumanchu_ |
the server does not "own" that, although it can guide it |
| 15:33 |
|
fumanchu_ |
I have to laugh every time I see server-side frameworks that have a class called "Application" (I have to laugh because my own, CherryPy, does too. otherwise I would cry) |
| 15:34 |
|
fumanchu_ |
that's like a hardware store having an aisle full of assembled houses instead of nails |
| 15:34 |
|
fumanchu_ |
offer the nails and let the user/agent decide how to *apply* them to its *application*, which could be different for each client |
| 15:35 |
|
|
azr joined #rest |
| 16:00 |
|
fuzzyhorns1 |
that's an interesting view, fumanchu_ |
| 16:00 |
|
fuzzyhorns1 |
i guess i always thought of hateoas as meaning the server leads a request/response cycle like a linked list through state transitions |
| 16:01 |
|
fumanchu_ |
I can't take credit. That's what Fielding means when he says "application" :P |
| 16:02 |
|
fuzzyhorns1 |
where does he say that? |
| 16:02 |
|
fumanchu_ |
google race! |
| 16:02 |
|
fuzzyhorns1 |
well he talks about application a lot :x |
| 16:02 |
|
fuzzyhorns1 |
i just meant were you thinking of a specific part |
| 16:03 |
|
|
quimrstorres joined #rest |
| 16:03 |
|
fumanchu_ |
some mailing list post I don't have at my fingertips made that clear to me years ago |
| 16:03 |
|
fuzzyhorns1 |
i _am_ trying to google it btw x) |
| 16:03 |
|
fumanchu_ |
:) |
| 16:03 |
|
fuzzyhorns1 |
do you remember the mailing list? :d |
| 16:04 |
|
sfisque |
searchbot google fielding rest term application definition |
| 16:04 |
|
searchbot |
sfisque: RESTful - Wikipedia: <http://en.wikipedia.org/wiki/Representational_state_transfer>; Fielding Dissertation: CHAPTER 5: Representational State Transfer ...: <https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm>; What is REST (representational state transfer)? - Definition from ...: <http://searchsoa.techtarget.com/definition/REST>; REST APIs must be hypertext-driven » (2 more messages) |
| 16:04 |
|
fuzzyhorns1 |
so then, should the server-side program not be an application? |
| 16:04 |
|
fuzzyhorns1 |
lol it always returns chapter 5, what's with that? |
| 16:04 |
|
sfisque |
chapter 5 is watching us |
| 16:04 |
|
fumanchu_ |
that's right. the server side is the stuff out of which the client may achieve its goals |
| 16:04 |
|
|
foist joined #rest |
| 16:05 |
|
fumanchu_ |
but the client may go to your competitor instead |
| 16:05 |
|
fumanchu_ |
yet retain the same application |
| 16:06 |
|
sfisque |
you can offer impls. if you have a "fabric", server<->server where one server offers rest, and other offers "representational implementation" like serving up flex clients or .net applets |
| 16:06 |
|
fuzzyhorns1 |
also have you guys ever seen http://roca-style.org/? |
| 16:06 |
|
fuzzyhorns1 |
wondered what you thought of it |
| 16:06 |
|
sfisque |
don't think of server as a single box or instance. rest is pretty much geared to fabric approach |
| 16:15 |
|
fuzzyhorns1 |
oh, i don't, at that, but it certain is a uniform boundary |
| 16:15 |
|
fuzzyhorns1 |
certainly* |
| 16:16 |
|
fumanchu_ |
usually a useful abstraction |
| 16:18 |
|
fuzzyhorns1 |
has anyone thought of applying rest to an application? |
| 16:19 |
|
fuzzyhorns1 |
literally applying the 4 interface constraints to a single application without necessarily reference to the web |
| 16:20 |
|
fumanchu_ |
there are some |
| 16:20 |
|
fumanchu_ |
mamund would know |
| 16:20 |
|
fumanchu_ |
:) |
| 16:20 |
|
fuzzyhorns1 |
oh i didnt even see mike was in channel |
| 16:20 |
|
fuzzyhorns1 |
hi mamund |
| 16:21 |
|
fumanchu_ |
I seem to recall some voip protocol... |
| 16:26 |
|
sfisque |
i would say the boundary is less "uniform" in a fabric. there is nothing wrong with having a legacy bridge system serve up a web application that is not built on rest, but aggregates some rest features found elsewhere in your fabric. i.e. you have a system that requires server managed state, but needs to consume rest style resources to handle it's workflows, and exposes its functionality to the client using "legacy web" semantics |
| 16:27 |
|
sfisque |
keep in mind that rest does not map to all types of workflows. there are cases where server maintained state is "by definition" and you have to accept that |
| 16:28 |
|
sfisque |
"accept that" == accept it as a contextual reality of the problem being solved |
| 16:40 |
|
whartung |
hateos basically documents the next paths on the graph available for the reseouce. Effectively, each resrouce comes with an abbreviated "you are here" guide with a list of transitions that you can use to move the resource to some other state. |
| 16:54 |
|
sfisque |
aye. i guess what i'm trying to convey is that not all "state transition" models necessarily map to a URI(verb) construct |
| 16:55 |
|
fuzzyhorns1 |
whartung: that is how i think of it too |
| 16:55 |
|
fuzzyhorns1 |
whartung: the tension i feel is that to make the client independent i want to send as much of that graph as i can |
| 16:55 |
|
whartung |
yes |
| 16:55 |
|
fuzzyhorns1 |
whartung: whereas to make sure the server can evolve, i want to send the minimal portion of the graph |
| 16:55 |
|
sfisque |
don't get me wrong, i'm not saying rest is crap or it's not useful. i just do not subscribe to the mantra that "the semantic web is everything" |
| 16:55 |
|
fuzzyhorns1 |
does that make any sense? |
| 16:56 |
|
fuzzyhorns1 |
id like it to be, sfisque, but i dont think it is true now x) |
| 16:56 |
|
sfisque |
i do not believe it could be. no architecture style solves everything |
| 16:56 |
|
sfisque |
as i said yesterday, utlimately rest is "part of the play book" |
| 16:56 |
|
whartung |
yea, but that doesn't bother me. I don't consider urls in links necessarily "cool" urls, (where cool urls in theory have a very long life). So, I don't feel there's that kind of contract with links in resources, making them more apt to change. |
| 16:57 |
|
sfisque |
aye |
| 16:59 |
|
fumanchu_ |
whartung: that list of transitions is to move your user/agent's application to some other state, not the resource |
| 17:00 |
|
fumanchu_ |
it's not HATEORS |
| 17:00 |
|
whartung |
yea, truth |
| 17:01 |
|
fuzzyhorns1 |
huh? how is it not hateoas? |
| 17:02 |
|
fuzzyhorns1 |
i thought hateoas is "hypermedia as engine of application state" |
| 17:02 |
|
fuzzyhorns1 |
not "engine of resource state" |
| 17:04 |
|
whartung |
that's his point. |
| 17:04 |
|
whartung |
"Application state", not "resource state" |
| 17:04 |
|
fuzzyhorns1 |
so what you described is not hateoas? |
| 17:04 |
|
fuzzyhorns1 |
i am just confused now |
| 17:04 |
|
fuzzyhorns1 |
what was the "it" of his sentence lol |
| 17:04 |
|
whartung |
that's why I agreed with fumanchu_ |
| 17:05 |
|
whartung |
the concept is the same, I simply mispoke |
| 17:05 |
|
fuzzyhorns1 |
i literally cant parse what you two mean right now lol |
| 17:05 |
|
fumanchu_ |
I meant "the acronym doesn't have an R, but an A" |
| 17:05 |
|
whartung |
"Hypermedia as an engine of Fuzzyhorns Confusion" |
| 17:05 |
|
fumanchu_ |
for a reason |
| 17:06 |
|
fumanchu_ |
:P |
| 17:06 |
|
fuzzyhorns1 |
AHHH ok |
| 17:06 |
|
fuzzyhorns1 |
i am not smart enough to get these jokes lol |
| 17:06 |
|
whartung |
so, here's a riddle. representation issue. |
| 17:06 |
|
fuzzyhorns1 |
whartung: haha pretty much |
| 17:06 |
|
fuzzyhorns1 |
easy to do ;) |
| 17:06 |
|
whartung |
we have a User resource (demographics, etc) |
| 17:07 |
|
whartung |
but also, it has the users roles for authorization |
| 17:07 |
|
whartung |
but |
| 17:07 |
|
whartung |
the roles are application specific |
| 17:07 |
|
whartung |
so, I'd like to provide an application "view" of the resource |
| 17:08 |
|
whartung |
so whaddy thing: (and I appreciate the irony being as I'm int he "I don't care" about urls camps, but…) |
| 17:08 |
|
whartung |
*think |
| 17:08 |
|
* fumanchu_ |
jumps the gun and answers "only 1 was going to St Ives!" |
| 17:09 |
|
fuzzyhorns1 |
whartung: sidebar: what does it mean to be in that camp? x) |
| 17:09 |
|
whartung |
/user/1234 dumps the entire user, maybe /user/1234?appid=recievables gives the app view? |
| 17:09 |
|
whartung |
we'll get to that in a minute fuzzyhorns1 |
| 17:09 |
|
whartung |
or should I simply have the app dig it's roles out of the user information, and publish it all? |
| 17:09 |
|
fuzzyhorns1 |
ime, namespacing by client essentially is bad news |
| 17:10 |
|
whartung |
yea, but it's a truth to be dealt with, so |
| 17:10 |
|
fumanchu_ |
so the "app view" is the set of roles? I don't yet understand what would be omitted |
| 17:10 |
|
whartung |
well, here's a simple example |
| 17:10 |
|
whartung |
two applications |
| 17:10 |
|
fuzzyhorns1 |
why scope by application though? rather than roles, which are independent resources? |
| 17:10 |
|
whartung |
invetory and recievables |
| 17:11 |
|
whartung |
each has a role "CAN_POST", that' their INTERNAL role (as these are independent apps). |
| 17:11 |
|
whartung |
but the master user data |
| 17:11 |
|
whartung |
can't simply add "CAN_POST" to the user, as that would give to role to both apps. |
| 17:11 |
|
whartung |
so instead |
| 17:11 |
|
whartung |
the user might have INV_CAN_POST and REC_CAN_POST |
| 17:11 |
|
fumanchu_ |
ah ok |
| 17:11 |
|
whartung |
which is mapped for the "app view" to CAN_POST for the respective apps |
| 17:11 |
|
fuzzyhorns1 |
that's the system i've seen before whartung |
| 17:12 |
|
fuzzyhorns1 |
minus mapping to app view |
| 17:12 |
|
fuzzyhorns1 |
i strongly recommend against that x) |
| 17:12 |
|
whartung |
Make me emperor of the universe, and I can have more control over name space issues fuzzyhorns1 , until then... |
| 17:12 |
|
fuzzyhorns1 |
i just mean, it won't help you, and there's an alternativer |
| 17:12 |
|
whartung |
I'm all ears |
| 17:12 |
|
fuzzyhorns1 |
so why not go with the alternative? |
| 17:13 |
|
whartung |
or eyeballs, as the case may be |
| 17:13 |
|
whartung |
could be using a text reader tho. |
| 17:13 |
|
fuzzyhorns1 |
you have a Permissions object that you independently can access |
| 17:13 |
|
fuzzyhorns1 |
haha i can see, but it is good not to assume |
| 17:14 |
|
whartung |
were you going to expand on the permissions object thing? |
| 17:16 |
|
fuzzyhorns1 |
yes sorry sec, thing on fire at work :d |
| 17:16 |
|
whartung |
ah ok no worries |
| 17:21 |
|
fumanchu_ |
assuming you're not going to Vary on Cookie or some other session-y approach, I would lean toward making a /user/1234/roles/inventory/ resource, perhaps with a URI Template link from /user/1234 so the last path segment could be variable |
| 17:22 |
|
fumanchu_ |
(and not include the roles data in /user/1234) |
| 17:23 |
|
fuzzyhorns1 |
fumanchu_: i would go even simpler, have a permissions/ resource, and query it with user and role params |
| 17:24 |
|
fumanchu_ |
that's more generic, but in my experience more generic is not always simpler |
| 17:25 |
|
fuzzyhorns1 |
true |
| 17:25 |
|
whartung |
that can work fumanchu_ |
| 17:25 |
|
fumanchu_ |
one question would be whether applications are evolving and need to self-register. will you need to support e.g. a POST to /roles/ to register a new set? |
| 17:26 |
|
fumanchu_ |
or is that a POST to /apps/ and then /user/1234/roles/otherapp is auto-created? |
| 17:27 |
|
whartung |
yea, they would…that implies that the apps are conscious of the mapping. But we can fake that, if we see a new role (from the app), we can always make up our own role for it (prefix it with the appid or something) |
| 17:27 |
|
fuzzyhorns1 |
i mean, only if you denormalize roles from permissions |
| 17:27 |
|
fumanchu_ |
sure |
| 17:28 |
|
whartung |
we also have to manage the mapping of roles to permissions, but the permissions are tied directly to the apps themselves, they're only indirectly connectd to the users. so there's not need to flatten those out in to a command namespace |
| 17:29 |
|
whartung |
*common namespace |
| 17:29 |
|
fuzzyhorns1 |
so a user has_many roles, and roles belong_to permissions, and apps have_many permissions? |
| 17:30 |
|
* fumanchu_ |
has a media-type which constrains the representations to make these kinds of decisions easy btw |
| 17:31 |
|
whartung |
I guess you could same roles "belong_to" permissions, but that's not how I think of it. Semantically that's probably true, but we'd always reprsent it as a list of permission for a specific role. |
| 17:31 |
|
whartung |
*could say |
| 17:31 |
|
fuzzyhorns1 |
fumanchu_: lessee! |
| 17:31 |
|
fumanchu_ |
https://bitbucket.org/fumanchu/shoji/src/f11eb85f65cbced875674ccfb283f8f08ff47e0d/spec.txt?at=default |
| 17:32 |
|
fuzzyhorns1 |
whartung: i think it is flexible, thats just my first impulse |
| 17:32 |
|
whartung |
I'll have to read that later fumanchu_ |
| 17:34 |
|
fumanchu_ |
np, fuzzyhorns1 asked :) |
| 17:34 |
|
fuzzyhorns1 |
fumanchu_: have you seen collection+json? or json-api etc |
| 17:34 |
|
fumanchu_ |
from time to time yes |
| 17:35 |
|
fumanchu_ |
IMO they're all too flexible |
| 17:35 |
|
fuzzyhorns1 |
collection+json is meant to be generic, but it is a strong generic hypermedia type imo |
| 17:35 |
|
fuzzyhorns1 |
json-api is pretty weak |
| 17:35 |
|
fuzzyhorns1 |
yours introduces a schema though |
| 17:35 |
|
fumanchu_ |
most have so few constraints they guide you toward caving in to the whims of frontend developers, not building scalable solutions by default |
| 17:37 |
|
fuzzyhorns1 |
that seems true to me on the face of it, but id like to read your thoughts more in depth on it |
| 17:37 |
|
fumanchu_ |
the spec has my best thoughts :) |
| 17:37 |
|
fumanchu_ |
e.g. https://bitbucket.org/fumanchu/shoji/src/f11eb85f65cbced875674ccfb283f8f08ff47e0d/spec.txt?at=default#cl-243 |
| 17:38 |
|
fumanchu_ |
or sec 2.2.1.2 |
| 17:38 |
|
fumanchu_ |
ff |
| 17:42 |
|
sfisque |
that's kind of by definition though. j in json == javascript with is horribly untyped |
| 17:43 |
|
sfisque |
so the question becomes how to build "type" into a system that is predicated on untyped data |
| 17:43 |
|
fuzzyhorns1 |
it is unityped as any dynamic lang |
| 17:43 |
|
whartung |
it's not horribly untyped, it has horrible implicit type promotion and conversion. |
| 17:43 |
|
fuzzyhorns1 |
i think the best you can do is contracts in that situation |
| 17:45 |
|
sfisque |
aye fuzzyhorns1 but like fumanchu says, you end up caving to the whims of the UX jockeys because they can "play havoc" with the data structure |
| 17:45 |
|
* sfisque |
dims a little while going into meeting mode |
| 17:45 |
|
* whartung |
meetings make me dim too... |
| 17:49 |
|
fumanchu_ |
breakfast time... |
| 18:02 |
|
fuzzyhorns1 |
fumanchu_: id be curious how your catalog abstraction is vs collection+json |
| 18:06 |
|
fumanchu_ |
one big difference at a quick glance seems to be collection+json doesn't really support collecting-without-containment |
| 18:06 |
|
fumanchu_ |
Shoji catalogs don't have to contain their members, they can merely refer to them |
| 18:07 |
|
fumanchu_ |
which in turn allows multiple differing catalogs over the same entities |
| 18:07 |
|
fumanchu_ |
or catalogs over non-entities, like a catalog of .jpegs |
| 18:11 |
|
fumanchu_ |
I'm really curious now why items.data is an array |
| 18:13 |
|
fumanchu_ |
by constraining the catalog.index and entity.body to be a "tuple" (JSON object), Shoji has a deterministic means of supporting PATCH, not just POST and PUT |
| 18:13 |
|
fumanchu_ |
(without actually turning the media type into a protocol!) |
| 18:21 |
|
fuzzyhorns1 |
i will try to look back at them both with that in mind, the collecting without containment thing is interesting to me |
| 18:37 |
|
|
_ollie joined #rest |
| 19:30 |
|
|
fumanchu joined #rest |
| 19:43 |
|
|
fuzzyhorns joined #rest |
| 19:50 |
|
|
azr joined #rest |
| 19:51 |
|
|
fuzzyhorns joined #rest |
| 19:51 |
|
fuzzyhorns |
fuzzyhorns: hi me |
| 19:51 |
|
fuzzyhorns |
ok good im i'd as myself |
| 20:28 |
|
|
quimrsto_ joined #rest |
| 20:42 |
|
mamund |
@fuzzyhorns, @fumanchu_ sorry i missed the discussion that included Cj. if you're still around, feel free to ping me. |
| 20:43 |
|
whartung |
MIKE! o/ |
| 20:43 |
|
mamund |
\o |
| 20:44 |
|
mamund |
wandered in here today ;) |
| 20:44 |
|
whartung |
how's your hammer hangin'? |
| 20:44 |
|
mamund |
{0.0} |
| 20:44 |
|
mamund |
whartung: will i see you at RESTFest year? |
| 20:45 |
|
whartung |
Is it in Costa Mesa? |
| 20:45 |
|
fumanchu |
whartung: are you hosting? |
| 20:45 |
|
whartung |
Not that I know of! |
| 20:45 |
|
fumanchu |
:P |
| 20:45 |
|
whartung |
But nobody tells me anything, so for all I know I hosted it last week. |
| 20:46 |
|
mamund |
LOL! not Costa Mesa -- Greenville, SC (as usual) |
| 20:46 |
|
whartung |
Yea, so, unlikely mamund |
| 20:46 |
|
mamund |
fumanchu: would be very cool to see you there, too. |
| 20:47 |
|
mamund |
whartung: what would it take to get you out this way? |
| 20:47 |
|
mamund |
srsly |
| 20:47 |
|
fumanchu |
thanks. busy busy though |
| 20:47 |
|
mamund |
awwwww |
| 20:47 |
|
fumanchu |
will have to see later |
| 20:47 |
|
fumanchu |
not ruling it out |
| 20:48 |
|
mamund |
again, would be cool to see you there. it's a great event (IIMSSM) |
| 20:48 |
|
whartung |
Convincing my wife :) |
| 20:48 |
|
mamund |
ha! would be happy to help you in that endeavor ;) |
| 20:50 |
|
mamund |
fumanchu: not sure if there is anything to discuss about Cj and containment (i think we've talked about it before re:shoji) but wanted to make sure to reach out. |
| 20:50 |
|
fuzzyhorns |
it would just be for my edification |
| 20:50 |
|
fuzzyhorns |
i havent had time today to read all of the shoji spec |
| 20:50 |
|
fuzzyhorns |
but at a high level i was curious about the distinction |
| 20:51 |
|
fuzzyhorns |
also hi mamund, im the zipcar dude bugging you by email and twitter :) |
| 20:51 |
|
mamund |
LOL, good to see you fuzzyhorns! |
| 20:52 |
|
mamund |
fumanchu can fill you in on shoji. i just wanted to make sure i addressed any Qs regarding Cj |
| 20:52 |
|
fuzzyhorns |
i just wanted to understand what collection without containment meant |
| 20:52 |
|
fuzzyhorns |
all i heard before was shoji does it, cj doesnt |
| 20:52 |
|
|
liamkeily joined #rest |
| 20:53 |
|
mamund |
right - IIUYC, Cj doesn't support "nesting" within the representation. if you want to indicate some data elementys are "children" of others, you do that w/ properties, not physically nesting. |
| 20:53 |
|
fumanchu |
a Shoji Catalog can have an index which links to a set of anything: images, csv's, any media type, not just shoji resources |
| 20:53 |
|
fumanchu |
and lets you annotate them in the catalog with additional attributes |
| 20:54 |
|
fuzzyhorns |
mamund: i dont think fumanchu meant nesting by what he described of shoji |
| 20:54 |
|
fuzzyhorns |
am i wrong fumanchu? |
| 20:54 |
|
mamund |
fumanchu: IIRC, shoji is a much more rich ecosystem than just a media type like Cj, right? |
| 20:54 |
|
mamund |
fuzzyhorns: ok, i might be way off the mark then. |
| 20:54 |
|
fumanchu |
I wouldn't call it an "ecosystem". it's a media type |
| 20:55 |
|
fumanchu |
it actually talks less about protocol than cj IMO |
| 20:55 |
|
mamund |
i see, you indicate protocl patterns, tho, right? conventions on ULS, no? |
| 20:55 |
|
fumanchu |
"discuss" more than "indicate" |
| 20:56 |
|
fumanchu |
Shoji is its own PATCH format, but there's no "you must use PATCH" verbiage |
| 20:56 |
|
fuzzyhorns |
fumanchu: so if i use shoji, am i still on my own figuring out what urls to post on, etc? |
| 20:56 |
|
fumanchu |
or "must use POST" for that matter |
| 20:56 |
|
fuzzyhorns |
hmm, why not leverage that in a media type, fumanchu? |
| 20:56 |
|
fumanchu |
because then you're describing a protocol, not a media type |
| 20:57 |
|
fuzzyhorns |
makes sense |
| 20:57 |
|
fumanchu |
the GIF media type doesn't say anything about what verbs to use when |
| 20:57 |
|
fuzzyhorns |
mamund: i ended up doing this: https://github.com/json-api/json-api/issues/619 |
| 20:57 |
|
fuzzyhorns |
fumanchu: do you have an equivalent in shoji to cj's write templates? |
| 20:58 |
|
fumanchu |
not in Shoji itself; my current corp has them for its API |
| 20:58 |
|
whartung |
one of my favorite media type example was one that Fielding used, where he sent a bit array as a GIF |
| 20:59 |
|
mamund |
fuzzyhorns: saw that. eould be nice to see more forms/templates in media type designs. Siren & Mason support them as do my Cj and UBER. |
| 20:59 |
|
fuzzyhorns |
whartung: ooh, where? |
| 20:59 |
|
whartung |
gah, hell if I know…"the internet" |
| 20:59 |
|
fuzzyhorns |
mamund: yeah, ive been meaning to check out siren |
| 21:00 |
|
mamund |
whartung: his way to "sticking it" to the pubsub crowd, IIRC. |
| 21:00 |
|
fumanchu |
:P |
| 21:00 |
|
whartung |
it was just a good example of "dont' get caught up on media type" and "media type is orthognal to the application" |
| 21:00 |
|
mamund |
fuzzyhorns: i refer to Siren as the HTML of the curly-brace world. ;) it has a very rich model that supports just about everything devs think they want today. |
| 21:00 |
|
fuzzyhorns |
how so, mamund? |
| 21:01 |
|
mamund |
on siren? |
| 21:01 |
|
fuzzyhorns |
mamund: sorry no the sticking it lol |
| 21:01 |
|
mamund |
hahaha! |
| 21:01 |
|
whartung |
Just like it took some time for Eric to pound in to my head about "just use HTML" rather tham xml-myapp-1.0 for media types |
| 21:01 |
|
fuzzyhorns |
mamund: how much community is there around siren? is it a registered type or? |
| 21:01 |
|
fumanchu |
!m Eric |
| 21:02 |
|
mamund |
he was saying that (as whartung points out) the _representation_ format is independent of protocol and internals. he whipped up a way to solve the pubsub problem over http w/o any apriori protocol patterns, etc. |
| 21:03 |
|
mamund |
siren is registered. there are def ppl using it. author kevin swiber is an apigee guy and apigee is using siren for their IoT libs. (zetta) |
| 21:03 |
|
fuzzyhorns |
mamund: hmm got enough keywords to google this? the way he solved it? |
| 21:03 |
|
mamund |
fielding? |
| 21:03 |
|
fuzzyhorns |
mamund: we're not quite at the hypermedia zoo chapter yet so heh |
| 21:03 |
|
fuzzyhorns |
mamund: yeah, im curious |
| 21:04 |
|
mamund |
search "paper tigers hidden dragons fielding" for his blog post |
| 21:04 |
|
fuzzyhorns |
ooh nice |
| 21:04 |
|
fuzzyhorns |
ty! |
| 21:06 |
|
mamund |
he did a similar thing to the WebDAV community's use of PROPFIND and other things. |
| 21:07 |
|
fuzzyhorns |
we need a list of "fielding's sickest burns" |
| 21:07 |
|
mamund |
;) |
| 21:07 |
|
fuzzyhorns |
anyway, time to go catch my commuter rail, have a good evening all |
| 21:08 |
|
mamund |
i wrote up an example implementation of that WebDAV thing here: http://amundsen.com/examples/fielding-props/ |
| 21:08 |
|
mamund |
Fielding's list post is here: http://www.xent.com/pipermail/fork/2001-September/004712.html |
| 21:10 |
|
mamund |
fumanchu: is application/shoji reg'd at IANA? |
| 21:11 |
|
fumanchu |
not yet; I had some things still to define even a couple months ago (added an Order object) |
| 21:12 |
|
fumanchu |
probably just need time now to register it |
| 21:12 |
|
mamund |
yeah - would be v. cool to get it up on the board so-to-speak |
| 21:12 |
|
* fumanchu |
moves it a couple inches up the inbox pile |
| 21:12 |
|
mamund |
even an early version would be helpful for other to see. |
| 21:12 |
|
mamund |
;) |
| 21:14 |
|
mamund |
ok, gonna wander off for a while, will return. |
| 21:15 |
|
* whartung |
last time he moved something up in his inbox pile, it fell off and landed in shredder. |
| 21:15 |
|
whartung |
kk take care mamund |
| 21:20 |
|
whartung |
oh that's clever |
| 21:20 |
|
whartung |
"Alternatively, we could define a single append-only resource per day and use partial GET requests to retrieve only the bits since the last poll, but that tends to be harder on the server." |
| 21:20 |
|
whartung |
the idea of using the http range headers to time block a request |
| 21:21 |
|
whartung |
I love it when one of my windows rings, but I have no idea which one it was. |
| 22:26 |
|
|
sfisque joined #rest |
| 22:35 |
|
|
azr joined #rest |
| 23:07 |
|
|
hucklebe_ joined #rest |
| 23:54 |
|
|
vanHoesel joined #rest |
