Time |
S |
Nick |
Message |
00:09 |
|
|
autrilla_ joined #rest |
00:17 |
|
|
seanbrant joined #rest |
01:14 |
|
|
shrink0r_ joined #rest |
01:35 |
|
|
shrink0r joined #rest |
02:02 |
|
|
autrilla joined #rest |
02:13 |
|
|
SlippinJimmy joined #rest |
02:59 |
|
|
huckleberry78 joined #rest |
03:01 |
|
|
autrilla_ joined #rest |
04:06 |
|
|
`0660 joined #rest |
04:09 |
|
|
dreamdust joined #rest |
04:55 |
|
|
Mxyzpltk joined #rest |
04:55 |
|
|
jsys joined #rest |
04:57 |
|
jsys |
"Many people think REST is about how to name their URLs. But that's not true. There's no such thing as a RESTful URL. That's not that REST is about." |
04:57 |
|
jsys |
Thoughts./ |
04:57 |
|
jsys |
http://www.infoq.com/presentations/rest-misconceptions |
05:03 |
|
|
autrilla joined #rest |
05:18 |
|
|
Mxyzpltk_ joined #rest |
05:33 |
|
jsys |
I've come to the conclusion that it's impossible to build a REST service without a known standard about the semantics of every action for a given mime type |
05:33 |
|
jsys |
And since we have no such common standard, with some exceptions (the web, feeds) |
05:33 |
|
jsys |
We can't have REST services, reallt |
05:46 |
|
jsys |
I'm pretty much saying REST is pie in the sky. |
06:27 |
|
|
lemur joined #rest |
07:04 |
|
|
autrilla_ joined #rest |
07:46 |
|
|
mgomezch joined #rest |
07:48 |
|
|
jsys joined #rest |
07:48 |
|
jsys |
What kind of standard entity can I use in order to represent a user |
07:48 |
|
jsys |
Or an order. |
07:49 |
|
jsys |
I'm basically saying what should I do so my REST client benefits from REST - by providing links to standard entities with known semantics |
08:03 |
|
trygvis |
what many people do is to invent their own media type and smack links into that |
08:03 |
|
trygvis |
that seems to work quite nicely for people and they get a lot of the benefits from rest and http |
08:05 |
|
jsys |
trygvis: "a lot" would be vastly overstating it |
08:05 |
|
jsys |
trygvis: it's a lot if there's a group of clients and a group of sites using the same entity format and semantics |
08:06 |
|
jsys |
trygvis: otherwise it's just "any API over HTTP" |
08:06 |
|
jsys |
trygvis: imagine if feed clients had to implement specific code for every site they read a feed of links from |
08:06 |
|
jsys |
trygvis: not very REST |
08:08 |
|
jsys |
trygvis: after all of REST was about "sending links to the client" one might as well not send links at all and rewrite standard pattern links to whatever they need for a areverse proxy |
08:13 |
|
trygvis |
once you start to follow the guidelines you *do* get a lot, that is a bit part of the point |
08:14 |
|
trygvis |
one people use frequently and early is simply caching and routing with intermediates |
08:14 |
|
jsys |
trygvis: what is "a lot" here, let's be specific |
08:14 |
|
jsys |
trygvis: what do we need RESTfulness for this? |
08:16 |
|
trygvis |
one example is to not invent your own authentication scheme, instead use what is already available so that agents know that this contains authentication and has to be treated specially |
08:17 |
|
jsys |
trygvis: but that's just HTTP |
08:18 |
|
jsys |
trygvis: we don't need resource-orientation or anything like this for authenticating |
08:18 |
|
trygvis |
if you can assume that your clients behave like http agents are expected to, and you want to move a server to a new host you can leverage routing to redirect clients and thus preserve old links |
08:18 |
|
jsys |
trygvis: or you can update your DNS to the new host. |
08:19 |
|
trygvis |
yes, but then you can't change the path |
08:19 |
|
jsys |
Why would I change the path |
08:19 |
|
trygvis |
and perhaps you can't have the same server running at two locataions |
08:19 |
|
trygvis |
locations |
08:20 |
|
jsys |
Of course I can, it's not like when you open google.com this is exactly one server behind it |
08:20 |
|
trygvis |
there are many reasons to change the paths too, for example you might deploy a new generation of your server side and are creating space for new URLs |
08:20 |
|
jsys |
trygvis: what does that mean "space for new paths" |
08:20 |
|
trygvis |
how can you decide that I can have my system running at two locations?.. |
08:21 |
|
jsys |
trygvis: there are many ways, and CDNs know all the tricks. Location sensitive DNS resolution, proxies, or basic routers |
08:21 |
|
jsys |
trygvis: you know how load balancers work so |
08:23 |
|
trygvis |
my system runs of a single postgresql instance, I can't run that in two locations so it would be nice to be able to support clients with old links until their links are updated and pointing to the new site |
08:23 |
|
jsys |
trygvis: what does sql have to do with this |
08:23 |
|
trygvis |
so with REST you get clients that are following links and I can start to redirect them from the old site to the new site without loosing clients or data |
08:23 |
|
jsys |
trygvis: you don't expose your SQL server to the web do you |
08:24 |
|
trygvis |
nothing, I was trying to argue that I can't have the same server in two locations |
08:24 |
|
jsys |
I'm not quite sure what it means, it's an oxymoron. |
08:24 |
|
jsys |
You can have two servers in two locations, or one server in one location. |
08:24 |
|
jsys |
You can't have one server in two locations. |
08:24 |
|
jsys |
But you can service one URL in many servers |
08:25 |
|
jsys |
A URL is not bound to one physical machine. |
08:25 |
|
trygvis |
I can't serve my site from different physical sites |
08:25 |
|
jsys |
Why not. |
08:25 |
|
jsys |
That's what all CDNs do |
08:25 |
|
trygvis |
because I use a sql server and I don't want to run a multi-master setup |
08:26 |
|
trygvis |
there is more to life than static data (which is what CDNs are most useful for) :) |
08:26 |
|
jsys |
trygvis: I still don't understand the problem. If you start pushing paths to another server you still have paths on two servers and one sql server |
08:28 |
|
jsys |
trygvis: it would be smarter to never change your paths and proxy the old location to the new one |
08:28 |
|
trygvis |
I can only run one http server |
08:28 |
|
jsys |
trygvis: ok I completely lost the plot here |
08:28 |
|
trygvis |
perhaps, but it is a question of flexibility you get from the architecture we're discussing |
08:28 |
|
jsys |
I don't understand what flexibility that is. |
08:28 |
|
|
_ollie joined #rest |
08:28 |
|
jsys |
This is what we're trying to determine. |
08:29 |
|
jsys |
For everything you say there's an existing simpler way to do it |
08:29 |
|
trygvis |
the ability to install a generic http agent that can I can use because I follow the rest style |
08:29 |
|
jsys |
That you can use how. |
08:30 |
|
jsys |
Without standard entities, that HTTP agent is only slightly smarter than a telnet session |
08:30 |
|
trygvis |
no, it's quite much smarter because you have a set of semantics your telnet client can't do |
08:30 |
|
jsys |
A browser is a generic HTTP agent, for example, that understands html/css/js/image entities so sure that's RESTful. |
08:30 |
|
trygvis |
can't do as in "doesn't know" |
08:30 |
|
jsys |
XML feeds - also RESTful |
08:30 |
|
jsys |
Proxy servers, mostly restful |
08:30 |
|
jsys |
But it stops there |
08:31 |
|
jsys |
trygvis: let me put it this way. I have a bunch of services right now working RPC style over HTTP. |
08:32 |
|
jsys |
trygvis: everything goes through POST, nulipotent requests are accepted over GET too |
08:32 |
|
jsys |
trygvis: a URL has the form of example.com/something/something/methodName and the arguments are passed over POST/GET fields |
08:32 |
|
jsys |
trygvis: what exactly do I win by going REST |
08:32 |
|
jsys |
I already use HTTP so I don't think basic HTTP is REST. |
08:32 |
|
jsys |
It's a bit more than that |
08:34 |
|
trygvis |
this seems like a good presentation: http://gotocon.com/dl/goto-amsterdam-2014/slides/StefanTilkov_RESTIDontThinkItMeansWhatYouThinkItDoes.pdf |
08:35 |
|
jsys |
trygvis: funny thing is I just saw that ;) |
08:35 |
|
jsys |
I also I think I pasted it here few hours ago |
08:35 |
|
trygvis |
yes, that is from the same guy |
08:35 |
|
trygvis |
not the exact same talk but probably mostly the same points |
08:35 |
|
jsys |
trygvis: but the point he drove home for me is that REST is awesome... when you have standard entities for standard clients to use |
08:35 |
|
jsys |
If you don't... there's... literally no benefit |
08:36 |
|
trygvis |
you seem convinced so I'm not sure how to argue against you |
08:36 |
|
jsys |
trygvis: so email is more REST than most APIs calling themselves REST |
08:36 |
|
jsys |
trygvis: well no I don't know. I guess my point is... where are the efforts to standardize the entities |
08:37 |
|
jsys |
trygvis: if we had that, REST would fly through the roof |
08:37 |
|
trygvis |
I think a bucket of sand is more REST than most APIs calling themselves REST. but that has more to do with the APIs than the sand :) |
08:37 |
|
jsys |
I really think we need standard entities for everything |
08:37 |
|
jsys |
That what would make REST useful |
08:37 |
|
trygvis |
perhaps, but there is still stuff to be gained from having smaller standard |
08:38 |
|
jsys |
Well, it won't be part of HTML, it'll be another series of standards |
08:38 |
|
trygvis |
definitely |
08:38 |
|
jsys |
As long as it's clear and accepted it'll benefit us |
08:38 |
|
trygvis |
but it's hard not to end up with SOAP when you try to standardize |
08:38 |
|
jsys |
Well SOAP didn't standardize entities. |
08:38 |
|
jsys |
It just standardized argument types. |
08:39 |
|
jsys |
Which is sliiiight;y similar, but different. SOAP describes types not semantics |
08:39 |
|
jsys |
you still need documentation to know what method "foo" does |
08:39 |
|
jsys |
If you have a standard with semantics, you DO know what method "foo" does |
08:39 |
|
jsys |
I mean you can easily have REST design over SOAP |
08:39 |
|
jsys |
Although it'll be ridiculously bloated |
08:40 |
|
jsys |
It's about them entities. Or well "resources" |
08:40 |
|
trygvis |
I'm working with accounting systems which is a world-wide domain and you would think that there where some useful standards where, but there is nothing |
08:41 |
|
jsys |
trygvis: welp |
08:41 |
|
jsys |
trygvis: you know how PayPal and so on have those little JS snippets and iframes to integrate payments in sites. |
08:41 |
|
trygvis |
yes |
08:41 |
|
jsys |
trygvis: imagine if we had "payment entity" or something that browsers understood and you just link to paypal.com' entity |
08:41 |
|
jsys |
No buttons or unsafe dialogs. |
08:41 |
|
jsys |
That's how I see REST |
08:42 |
|
jsys |
But without client support and standards, I feel like it's mostly bloat. |
08:42 |
|
jsys |
I mean why send back links... |
08:42 |
|
trygvis |
it might not be a good fit for you, many people need RPC and tight integration |
08:42 |
|
jsys |
if you still need documentation to know what the link names mean |
08:43 |
|
trygvis |
you will always need documentation for your links, even if it is a standardized link |
08:43 |
|
jsys |
If I was creating some open standard for chat, payments, social networking, etc etc I would definitely pursue REST |
08:43 |
|
jsys |
With standard entities and so on |
08:43 |
|
jsys |
But otherwise, yeah |
08:43 |
|
jsys |
It's kinda... |
08:43 |
|
trygvis |
even the standard ones have documentation: http://www.iana.org/assignments/link-relations/link-relations.xhtml |
08:44 |
|
jsys |
trygvis: my point is the documentation is one for the standard, not one per API implementation |
08:44 |
|
trygvis |
sure |
08:44 |
|
jsys |
So then you implement a client once and all sites provide named link, and the client knows what the link names are. |
08:44 |
|
jsys |
It's subtle but very different |
08:45 |
|
trygvis |
today there is an independent list of link relations which is intented to be useful from 'any' hypermedia (or any media really) |
08:46 |
|
jsys |
trygvis: it's just a bit of indirection in links tbh |
08:46 |
|
trygvis |
but to be honest I have no hope that the kind of stuff that you're talking about will be standardized |
08:46 |
|
jsys |
trygvis: and if I had to implement that, I wouldn't return links bloating my entities. There's an HTTP header for that (tm) |
08:46 |
|
jsys |
trygvis: you can have one standard URL for this, and return Permanently Moved from it |
08:46 |
|
jsys |
trygvis: with the new location. |
08:47 |
|
jsys |
trygvis: it's more efficient too, no need to send back links all the time |
08:47 |
|
trygvis |
and I very seldom see the big upside by global standards, they become extremely inflexible. which can be a good thing, but often a bad thing too |
08:48 |
|
jsys |
Don't you agree though about permanently moved |
08:48 |
|
jsys |
Its kind of another way to do the same thing |
08:48 |
|
trygvis |
including all of the links in every request gives you flexibility to reuse the resource |
08:48 |
|
jsys |
trygvis: how |
08:48 |
|
trygvis |
it is a concequence of the REST style |
08:48 |
|
jsys |
No really, how |
08:48 |
|
jsys |
Let's say I have a resource /foo |
08:49 |
|
jsys |
And I say in my docs "append number to this and you get a resource of that id" |
08:49 |
|
jsys |
Then I go to /foo/86 and I get it. And if I change server I send back 301 |
08:49 |
|
jsys |
And that's that |
08:50 |
|
jsys |
Or even better I just have my routers deal with it and I always expose one style |
08:50 |
|
jsys |
trygvis: if you are the only one who implements your entities, it never makes sense to send back links all the time |
08:50 |
|
jsys |
trygvis: because they always point back to YOUR infrastructure |
08:51 |
|
jsys |
trygvis: if it was a standard, THEN it becomes useful to have hyperlinks |
08:51 |
|
jsys |
Cause you can point to Bob's server |
09:06 |
|
|
autrilla joined #rest |
09:08 |
|
|
interop_madness joined #rest |
09:22 |
|
jsys |
Once you understand REST, you understand 99.99% of RESTful APIs are merely cargo cult of the idea of it. |
09:23 |
|
_ollie |
well, once you understand REST, you understand that 99% of the APIs claiming to be REST are not REST actually ;) |
09:23 |
|
jsys |
99% is too generous |
09:24 |
|
jsys |
Thing is, you can't really just implement a REST service. |
09:24 |
|
jsys |
You need to have a REST client waiting for it. |
09:24 |
|
jsys |
And there are a handful of REST clients out there. |
09:24 |
|
jsys |
Search engines, browsers, feed readers and... that's about it. |
09:24 |
|
jsys |
Maybe some smaller ones. |
09:25 |
|
jsys |
"A service specific REST entity" is like an "application specific platform API" |
09:25 |
|
jsys |
It's an oxymoron |
09:28 |
|
jsys |
_ollie: the thing one doesn't expect, is they're in the 99.999% that don't get it right |
09:29 |
|
jsys |
_ollie: it's physically impossible for someone to implement a REST service even if they want to, unless its semantics are fully exhausted by the existing standards |
09:29 |
|
jsys |
_ollie: unless you're Google or Microsoft, then you can invent your own standards. |
09:29 |
|
jsys |
And push for them |
09:35 |
|
jsys |
In fact, I doubt there's a single person in this channel actually having RESTful design |
09:39 |
|
|
mezod joined #rest |
09:40 |
|
|
shrink0r joined #rest |
10:00 |
|
|
azr joined #rest |
10:05 |
|
|
vanHoesel joined #rest |
10:22 |
|
|
dEPy joined #rest |
10:25 |
|
|
Left_Turn joined #rest |
10:48 |
|
interop_madness |
what constitutes RESTful design then, actually? |
10:49 |
|
_ollie |
jsys: I built a couple of systems that I think meet all constraints of REST… |
10:51 |
|
interop_madness |
in my webservice, i adhere to the RFCs 2045, 2046, 2388, 2616,3986, 5987, 6266, 7231, and 7232, use the suitable HTTP verbs for each request, adhere to HATEOAS principles, use media type headers, etc. |
10:52 |
|
interop_madness |
not sure what else i could do besides introducing PATCH requests |
11:02 |
|
jsys |
_ollie: what do these serices do |
11:02 |
|
jsys |
_ollie: is there a client that can use your services without some sort of documentation you provide |
11:02 |
|
jsys |
_ollie: the way a browser uses HTML/CSS/JS/image resources |
11:03 |
|
jsys |
Without browser makers reading site-specific documentation and implementing it site by site |
11:08 |
|
|
autrilla_ joined #rest |
11:26 |
|
interop_madness |
jsys, that requirement is adressed with HATEOAS and OPTIONS |
11:27 |
|
interop_madness |
more precisely link relations |
11:31 |
|
jsys |
interop_madness: defined, but not sufficiently. |
11:31 |
|
jsys |
interop_madness: in a real application you'd have to send back hundreds of links to define all possible relations |
11:32 |
|
jsys |
interop_madness: HATEOAS and so on are baby steps to a benefit that's as of yet unrealized |
11:32 |
|
interop_madness |
jsys, it would suffice to have a base URL which links to each possible, resource, each of which serve OPTION requests and/or provide further link relations for GET |
11:33 |
|
interop_madness |
possible resource* |
11:33 |
|
jsys |
interop_madness: with those links you can scan a graph of resources |
11:33 |
|
jsys |
interop_madness: but you have no idea either 1) what those resources are |
11:34 |
|
jsys |
interop_madness: nor 2) what put/post does for them, nor what effect DELETE has on them |
11:34 |
|
jsys |
interop_madness: so tons of links later you have a graph of noise basically |
11:35 |
|
interop_madness |
jsys, what can be expected from PUT, POST and DELETE is defined in RFC2616. either the webservices adheres to this or it doesn't adhere to http altogether |
11:36 |
|
jsys |
interop_madness: I don't mean the semantics of the operation. I mean you still have no idea either what PUT/POST expects, or what is the effect of deleting a resource that you don't know what it represents. |
11:36 |
|
jsys |
interop_madness: a client which can get/set/delete anonymous unexplained objects... still can't do a thing that's useful |
11:37 |
|
jsys |
interop_madness: you either need standard formats, or specific clients |
11:37 |
|
jsys |
interop_madness: we don't have the former, and the latter won't realize REST's benefits |
11:37 |
|
interop_madness |
also, at some point the consumer has to infer what the entity returned by GET is all about. the same argument can be made for webbrowsers. GET www.google.com returns some HTML, but what is it for, really? we just happen to infer that from the document presented |
11:38 |
|
jsys |
interop_madness: the people infer it |
11:38 |
|
jsys |
interop_madness: and with some success search engines do |
11:38 |
|
jsys |
interop_madness: a browser without a person attached to it is useless. |
11:38 |
|
jsys |
interop_madness: so the question is why have services at all if we can infer everything through human readable web pages? |
11:39 |
|
jsys |
interop_madness: the reason we expose machine readable APIs is so they don't need a human attached |
11:39 |
|
jsys |
interop_madness: so.. we have a problem here right |
11:40 |
|
interop_madness |
maybe there should be a DOCUMENTATION request together with a media type for it |
11:40 |
|
jsys |
interop_madness: and it should returns a WSDL right ;) |
11:41 |
|
interop_madness |
but i'm not sure about the notion of machine-readability. SOAP WSDLs can be imported pretty trivially to generate proxy classes for consumption, still the programmer has to compose some code out of them |
11:41 |
|
jsys |
interop_madness: the problem is again a documentation can at best describe the schema of the entity |
11:41 |
|
jsys |
interop_madness: it can't describe the meaning of it |
11:41 |
|
jsys |
interop_madness: REST requires very very specific resources to be defined as standards, so generic clients understand them deeply |
11:41 |
|
interop_madness |
i don't think that can be expressed by any formal language without restrictions that make it pointless |
11:41 |
|
jsys |
interop_madness: without that... it's just SOAP by another wire protocol |
11:42 |
|
jsys |
interop_madness: well I'm not saying such format language exists. |
11:42 |
|
jsys |
interop_madness: I'm saying we need standard formats for common things |
11:42 |
|
jsys |
interop_madness: then generic clients can be built to use those formats |
11:42 |
|
jsys |
interop_madness: things like identity, orders, carts, dunno |
11:43 |
|
jsys |
interop_madness: like posts, articles |
11:43 |
|
jsys |
news items? who knows |
11:43 |
|
jsys |
whatever we want reusable |
11:43 |
|
jsys |
We did it for feeds. |
11:43 |
|
jsys |
A feed is a REST standard entity basically. |
11:43 |
|
jsys |
Atom and RSS |
11:43 |
|
interop_madness |
that's an arbitrary selection that maps to some real world usages but going that way results either in a limited REST applicability altogether or in a format explosion |
11:44 |
|
jsys |
interop_madness: well that's why I feel REST holds a promise it can't realize. |
11:44 |
|
jsys |
interop_madness: it's wildly useful for a widely propagated set of restricted standard entities |
11:44 |
|
jsys |
interop_madness: the way html/css/js/img are now |
11:44 |
|
jsys |
interop_madness: but if you use your own entities... then there's little to no benefit |
11:45 |
|
interop_madness |
is machine comprehension really something REST promised? |
11:45 |
|
jsys |
I don't think it promised automatic comprehension. |
11:45 |
|
jsys |
But it's comprehension by standardized machine readable resources. |
11:45 |
|
jsys |
And yes, in a way everything REST promises ... uhmm "RESTs" on this |
11:45 |
|
jsys |
:P |
11:46 |
|
jsys |
Without a proliferation of usable standard entities it's really just.. "oh get won't mutate a resource" |
11:46 |
|
jsys |
And ... uhmm basics like this, which don't amount to anything without service-specific code |
11:47 |
|
jsys |
interop_madness: imagine, say, a payment entity you can drop in any site |
11:47 |
|
jsys |
from another server |
11:47 |
|
jsys |
no more "pay with paypal" buttons, instead, RESTful implementation with an entity |
11:47 |
|
jsys |
Right inline and so on |
11:47 |
|
jsys |
That's the kind of stuff we need |
11:49 |
|
interop_madness |
it's not that i don't agree to a world with few (even bad) standards rather than gazillions of competing ones |
11:49 |
|
interop_madness |
i just guess i need to read Fielding's dissertation completely, because i fail to see how this goal was mentioned |
11:50 |
|
interop_madness |
so far i read only excerpts :/ |
11:50 |
|
jsys |
In general the paper discusses one should reuse interactions and formats. |
11:50 |
|
jsys |
So less ad-hoc formats. |
11:51 |
|
jsys |
And that's true both within one project, and the world as a whole. |
11:51 |
|
jsys |
But... without standards, everything is ad-hoc so |
11:51 |
|
jsys |
It's a big hurdle to overcome |
11:52 |
|
jsys |
interop_madness: an example would be microformats like vCard. Algorithms exist to guess address and phone info from any plain text, but a microformat is way more reliable. |
11:52 |
|
jsys |
interop_madness: REST is about microformats at the resource level |
11:52 |
|
jsys |
Things a machine knows what they are. |
11:52 |
|
jsys |
Without guesswork |
11:53 |
|
jsys |
Maybe not for all of it, but the more the merrirer |
11:54 |
|
jsys |
Anyway gotta go, nice chat ;) |
12:03 |
|
|
Andre-B joined #rest |
12:48 |
|
|
warehouse13 joined #rest |
12:53 |
|
|
warehouse13 joined #rest |
13:07 |
|
|
azr joined #rest |
13:09 |
|
|
autrilla joined #rest |
13:32 |
|
|
jsys joined #rest |
13:34 |
|
jsys |
You know what... I can't remember if REST was ever originally recommended as a way for implementing service APIs |
13:45 |
|
pdurbin |
jsys: well, this is from the person who coined "REST": http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven |
13:46 |
|
jsys |
pdurbin: so he's kinda drinking his kool aid huh |
13:46 |
|
jsys |
pdurbin: I've been thinking... Fielding definitely described why the architecture of the web works, but the architecture of the web was never intended to expose service APIs |
13:47 |
|
jsys |
pdurbin: so while I understand his frustration in people calling things REST that aren't REST |
13:47 |
|
pdurbin |
jsys: in this channel no one has ever linked to a truly REST API: http://irclog.greptilian.com/rest/2015-02-24#i_98704 |
13:47 |
|
jsys |
pdurbin: the question to me is open if REST is in fact the best way to expose an API |
13:48 |
|
jsys |
pdurbin: yeah |
13:49 |
|
jsys |
pdurbin: I guess the problem is that for something to be RESTful you need a small number of standard entities clients can work with. If you have your own entities... then.... there's no reason to go REST |
13:50 |
|
jsys |
pdurbin: there's something else I've been wondering about |
13:51 |
|
jsys |
pdurbin: Fielding described REST by observing how the web works |
13:51 |
|
jsys |
pdurbin: but it's been described as if the web works like this by some grand design |
13:51 |
|
trygvis |
pdurbin: here is one that's decent: http://developer.runkeeper.com/healthgraph/overview |
13:51 |
|
jsys |
pdurbin: while if you follow how every one of the REST contstraints and features were developed for the web... you'd see it's been ad-hoc and driven by current demand for something. |
13:52 |
|
jsys |
pdurbin: in a way, the web has grown DESPITE naysayers demanding it's already perfect. The history of the web is one of design growing organically by breaking previous limits. |
13:52 |
|
jsys |
pdurbin: and now we're asked to stop breaking those limits... Suspicious? |
13:53 |
|
jsys |
trygvis: what about my thoughts on the evolution of the web. Opinion? |
13:53 |
|
pdurbin |
trygvis: cool. thanks |
13:55 |
|
jsys |
trygvis: this API goes through the motions, but to what end? |
14:00 |
|
fumanchu_ |
read his dissertation again and again until you see the end |
14:00 |
|
fumanchu_ |
you will be a much better programmer |
14:00 |
|
jsys |
fumanchu_: I know what the general model of the web is, which the dissertation is based upon. I'm asking about THIS particular API. |
14:01 |
|
fumanchu_ |
your questions reveal you do not |
14:01 |
|
fumanchu_ |
read and learn |
14:01 |
|
jsys |
fumanchu_: that's a strange way to say "I have no answer" |
14:01 |
|
fumanchu_ |
no. it's a way of saying "you can't possibly learn in a short IRC conversation all that you need to know" |
14:02 |
|
jsys |
fumanchu_: you can't articulate why the healthgraph API should be REST do you |
14:02 |
|
fumanchu_ |
punk |
14:02 |
|
jsys |
Well, you're not quite as eloquent as Fielding is. |
14:04 |
|
jsys |
fumanchu_ if you're designing an API for your boss, and your boss asks "why is it REST" would you send him off to re-read the dissertation until you get it? |
14:05 |
|
jsys |
until he gets it* |
14:05 |
|
fumanchu_ |
no. I would expect he hired me because of my expertise which he would trust to a certain extent. not challenge without undertanding |
14:05 |
|
jsys |
fumanchu_: everything is done to some end. Design is not abstractly good, it has purpose. |
14:05 |
|
jsys |
fumanchu_: so asking "why" you see as challenge. |
14:05 |
|
jsys |
fumanchu_: you must feel quite insecure in your expertise |
14:06 |
|
fumanchu_ |
heh |
14:13 |
|
jsys |
the value of REST for APis is this kind of blackhole where everyone points to the dissertation and no one comes back to explain it in real world term. |
14:14 |
|
fumanchu_ |
the values of a REST architecture for any system are clear: scalable systems. evolvable systems. whether those are useful in your system is up to you. |
14:15 |
|
jsys |
fumanchu_: you're basically saying nothing right now. "REST is double plus good" is equivalent in terms of why *specifically* REST results in more scalable/evolvable systems and compared to *what* |
14:16 |
|
|
kaos|work joined #rest |
14:16 |
|
fumanchu_ |
exactly. which is a very complex subject and requires more space to go into than an IRC channel. it takes the equivalent of a college course in Architecture |
14:17 |
|
jsys |
fumanchu_: that's because you keep driving to some general point I'm not asking about |
14:17 |
|
jsys |
fumanchu_: we have a specific API here, the Healthgraph |
14:18 |
|
jsys |
fumanchu_: why would that specific API benefit in the next, say 3-4 years, from being REST |
14:18 |
|
jsys |
It requires a college course to explain for this API because it'll take you several years to figure out what to say |
14:19 |
|
jsys |
Ths API could've been easily just... RPC |
14:19 |
|
jsys |
No difference at all. Zero. |
14:19 |
|
jsys |
No one else implements this graph, chances are no one ever will |
14:19 |
|
jsys |
All those URLs will point to the same infrastructure, might as well have been hard number ids |
14:19 |
|
jsys |
It's all a cargo cult |
14:20 |
|
jsys |
But hey who knows maybe it'll explode into the web of healthgraphs! |
14:20 |
|
jsys |
Just like them cargo cults thought the plane will land on their fake landing strip |
14:20 |
|
fumanchu_ |
sounds like scale and evolution aren't valuable to your system then. go use rpc |
14:21 |
|
jsys |
fumanchu_: another generic "seems like you hate Jesus, cause Jesus likes REST" argument |
14:21 |
|
fumanchu_ |
haha |
14:21 |
|
jsys |
fumanchu_: utterly unconvincing |
14:21 |
|
fumanchu_ |
I should be writig this down |
14:21 |
|
jsys |
Yup, you can use it next time |
14:24 |
|
fumanchu_ |
"I don't want to buy your boat until I understand fluid dynamics. why isn't it a truck?" "sounds like you want a truck" "you're a cargo cult!" |
14:24 |
|
jsys |
fumanchu_: have you thought web browsers are the biggest pigs on most people's computers? There's hardly ever a heavier app on someone's computer, unless he's a professional using pro apps. |
14:24 |
|
jsys |
fumanchu_: what if THIS is the price to pay for REST? |
14:25 |
|
jsys |
What if it has a lot of overhead and it only becomes useful if everyone adopts it at once, like it happened (ONCE) for HTML? |
14:25 |
|
jsys |
If this single application of REST, HTML, wasn't around, would Fielding had something to retcon into a dissertation? No. |
14:26 |
|
fumanchu_ |
lol |
14:26 |
|
fumanchu_ |
Fielding wrote that while building the Apache web server. "retcon" is a joke. |
14:27 |
|
jsys |
fumanchu_: you're saying it like Apache was the invention of web servers. |
14:27 |
|
jsys |
fumanchu_: if I write a web server can I write a paper titled "Ok REST kind of sucks" |
14:27 |
|
fumanchu_ |
YES |
14:27 |
|
jsys |
Would you believe it? |
14:27 |
|
fumanchu_ |
go write one |
14:27 |
|
jsys |
Ok full disclosure I have |
14:27 |
|
jsys |
REST kind of sucks. |
14:28 |
|
fumanchu_ |
yay! now we can be done |
14:28 |
|
shrink0r |
fumanchu_: I'm with you. I guess in some cases practical experience can save the day ^^ and lead to more acceptance/understanding |
14:29 |
|
fumanchu_ |
jsys: this one? http://www.izysoftware.com/products/saetta-server/saetta-web-server/ |
14:30 |
|
jsys |
shrink0r: you know this is kinda how Scientology works too. "You kinda have to read Ron Hubbard's books and spend 5 years in our cult in order to understand" |
14:30 |
|
jsys |
I'll take my 5 years and go elsewhere, thanks |
14:30 |
|
fumanchu_ |
bye |
14:30 |
|
shrink0r |
well, actually I was trying to say, that software has a slow feedback loop |
14:31 |
|
fumanchu_ |
it's also how academia works |
14:31 |
|
jsys |
No, not literally. I'll stay here to remind you REST sucks |
14:31 |
|
fumanchu_ |
and ohI don't know, engineering |
14:31 |
|
shrink0r |
jsys: so hindsight is a casual thing |
14:31 |
|
jsys |
fumanchu_: engineering has a very clear goal and a very clear method |
14:32 |
|
shrink0r |
but you seem to be very sure about you opinion |
14:32 |
|
jsys |
fumanchu_: instead the things you talk about might as well be "do REST and you get 70 virgins in heaven" |
14:32 |
|
fumanchu_ |
you do! |
14:32 |
|
jsys |
fumanchu_: do they support PUT or just GET |
14:33 |
|
shrink0r |
jsys: that's http, which has nothing to do with rest |
14:33 |
|
shrink0r |
:P |
14:33 |
|
jsys |
shrink0r: nothing huh :) |
14:33 |
|
shrink0r |
nothing √ |
14:34 |
|
jsys |
shrink0r: oh I bet it has nothing to do with it. I guess no one really uses HTTP to do REST APIs. |
14:34 |
|
jsys |
You're right. |
14:34 |
|
jsys |
I also suppose Fielding just invented REST, he didn't have an example to go from. |
14:34 |
|
shrink0r |
they are often seen together |
14:34 |
|
jsys |
It's all just a giant coincidence. |
14:34 |
|
jsys |
shrink0r: I've never seen REST and HTTP in the same room actually |
14:34 |
|
shrink0r |
and rest is a good fit for designing http communication |
14:35 |
|
shrink0r |
but you are the perfect example that http comes without rest and as you state seems to be better off that way |
14:36 |
|
jsys |
shrink0r: it's a good fit if you distribute various anonymous objects without care about consistency or semantics. |
14:36 |
|
jsys |
shrink0r: in other words it's good for hypertext |
14:36 |
|
jsys |
And nothing else |
14:37 |
|
fumanchu_ |
HTTP and URI were designed using the REST architectural style. To believe that your HTTP API can decide whether to use REST or not is a non sequitur. |
14:38 |
|
jsys |
fumanchu_: oh so everything I do on HTTP is REST right? |
14:38 |
|
jsys |
fumanchu_: ok glad we clarified this |
14:39 |
|
jsys |
fumanchu_: you kinda walked right into that one |
14:39 |
|
fumanchu_ |
never sorry to walk into the truth |
14:40 |
|
jsys |
fumanchu_: we have shrink0r here saying HTTP and RESt have nothing in common and you saying HTTP is REST so you cna't not do REST on HTTP. The sum of all this is a giant cup of B U L L S H I T |
14:40 |
|
jsys |
fumanchu_: XML is also a markup language so I bet you can never not do markup in it. |
14:40 |
|
jsys |
fumanchu_: like in the 90s when everyone suddenly decided it's a serialization format for machine data |
14:41 |
|
jsys |
fumanchu_: but I guess it's also extensible markup, if you read it like prose the c86 equivalent or a Shakespeare is somewhere in there |
14:41 |
|
shrink0r |
jsys: I am not trying to prove you wrong, but to help you (and me?) gain a better understanding |
14:41 |
|
jsys |
x86* |
14:41 |
|
shrink0r |
jsys: if this is how you would like to elaborate .... |
14:41 |
|
jsys |
shrink0r: I do get the point about REST as a concept being abstract. |
14:41 |
|
shrink0r |
I personally like this post: http://www.looah.com/source/view/2284 |
14:42 |
|
jsys |
shrink0r: I do also get the benefits realized on the web via HTTP and RESTful design. |
14:42 |
|
shrink0r |
because it is short and gives a good idea that rest is not all about http, but about architecture |
14:42 |
|
jsys |
shrink0r: and also no, none of this cargo cultishly translates to magical benefits for a service API |
14:42 |
|
shrink0r |
and how to communicate (among machines) |
14:42 |
|
jsys |
shrink0r: it's just a lowest common denominator crap layer everyone tunnels their shit through. How about this dose of realism. |
14:43 |
|
jsys |
We had SOAP now we have REST and JSON |
14:43 |
|
jsys |
That's the truth |
14:43 |
|
jsys |
Nothing has changes, it's just a different type of fucked up |
14:43 |
|
jsys |
Something else will replace it. |
14:43 |
|
fumanchu_ |
indeed |
14:44 |
|
jsys |
I actually hope we'll eventually figure out what Alan Kay said decades ago and stop modeling everything as request and responce. |
14:44 |
|
jsys |
It's simple, but completely arbitrary |
14:44 |
|
jsys |
You send a message you may not need one back. |
14:44 |
|
jsys |
You may need two back. |
14:45 |
|
jsys |
You may need someone ELSE to get the message, not you |
14:45 |
|
jsys |
Request/REsponce is not a marvel of architecture, it's just the first thing that occured to whoever implemented it |
14:45 |
|
_ollie |
No one argues that… |
14:46 |
|
* fumanchu_ |
is still looking on the Net for jsys web server |
14:46 |
|
_ollie |
you do something in a particular way… that has certain consequences… if these consequences align with your requirements, perfect… if not, change the way you implement stuff… |
14:46 |
|
jsys |
fumanchu_:, you'll find it keep goin |
14:47 |
|
jsys |
_ollie: that'snot the kind of vibe I get from the RESt community. Otherwise.. of course |
14:47 |
|
jsys |
_ollie: instead I get told to re-read the dissertation of fielding until "I get it" |
14:47 |
|
_ollie |
jsys: https://www.youtube.com/watch?v=UkAt9XSOfaE&index=45&list=WL |
14:47 |
|
_ollie |
the first 10 minutes here outline this pretty much… |
14:47 |
|
jsys |
If I keep re-reading something eventually I'll "get it" even if it's the latest rant from Bill O'Reilly |
14:48 |
|
_ollie |
well if you contextualize the dissertation then that's exactly what you get… |
14:49 |
|
_ollie |
the dissertation just describes that way of doing things and outlines the consequences you get |
14:49 |
|
_ollie |
basically analyzing HTTP for it's core characteristics… |
15:10 |
|
|
azr joined #rest |
15:11 |
|
|
autrilla_ joined #rest |
15:29 |
|
|
sgalvez joined #rest |
15:33 |
|
jsys |
_ollie: I saw it but still no one is explaining the rotating knives |
15:44 |
|
jsys |
The only thing that happens every time I revisit that dissertation is I find more holes. |
15:46 |
|
shrink0r |
jsys: maybe you could write up what you think and be the first to explain |
15:46 |
|
jsys |
shrink0r: that's now things happen. |
15:47 |
|
jsys |
shrink0r: we tend to think our belief in things are based on reason and argument. |
15:47 |
|
jsys |
shrink0r: actually it's mostly peer pressure, habituation and emotional appeal |
15:47 |
|
jsys |
shrink0r: some people can argue hard enough that earth is flat, and find plenty of arguments in their support. |
15:47 |
|
shrink0r |
yes, that's how we've been rolling the last thousand of years |
15:48 |
|
jsys |
shrink0r: hah |
15:48 |
|
shrink0r |
and will for I dont how long ^^ |
15:48 |
|
jsys |
shrink0r: maybe... I'll write about REST in a blog... and put a stop to that :P |
15:48 |
|
shrink0r |
we still need to find a way to build acceptable software while progressing a towards a maybe more desirable state |
15:49 |
|
shrink0r |
-a |
15:49 |
|
jsys |
shrink0r: well things with desirable state, especially with computers, the "good enough" barrier is crossed very fast. |
15:49 |
|
jsys |
shrink0r: and it stops there. |
15:50 |
|
jsys |
shrink0r: we desire more efficient software, but computers get faster, software slows down to compensate. Are we progressing towards a more desirable state? Hardly. |
15:50 |
|
jsys |
shrink0r: the web is quite far from flawless. And REST has some constraints which I'm quite sure are irrelevant to the web's success. |
15:50 |
|
shrink0r |
good enough is the tricky part, because "good enough" is a temporal snapshot within a highly dynamic context |
15:50 |
|
shrink0r |
good enough today, can be terrible tomorrow |
15:51 |
|
jsys |
shrink0r: eh of course |
15:51 |
|
jsys |
sure but my point is engineering doesn't get better |
15:51 |
|
shrink0r |
that's where experience etc. kick in |
15:52 |
|
jsys |
I kinda miss the times where we bit-packed stuff to save a byte on the wire :/ |
16:04 |
|
|
vanHoesel joined #rest |
16:10 |
|
|
azr joined #rest |
16:12 |
|
|
sgalvez joined #rest |
16:48 |
|
|
lemur joined #rest |
17:13 |
|
|
autrilla joined #rest |
17:22 |
|
whartung |
lol jsys |
17:33 |
|
|
shrink0r joined #rest |
17:40 |
|
|
Mxyzpltk joined #rest |
17:43 |
|
jsys |
I like how HTTP2 makes HTTP1 seem like a broken design |
18:18 |
|
pdurbin |
jsys: how so? |
18:21 |
|
jsys |
pdurbin: http://http2.github.io/faq/ |
18:21 |
|
jsys |
pdurbin: this FAQ pretty much calls HTTP1.x names all the time |
18:21 |
|
jsys |
pdurbin: :) |
18:21 |
|
jsys |
"Oh it clogged our pipes and clogged congestions and TCP wasn't made to be abused like that. Damn HTTP1 |
18:22 |
|
jsys |
"HTTP2 much better! HTTP1 bad." |
18:22 |
|
pdurbin |
fightin' words |
18:23 |
|
jsys |
pdurbin: a lot of the REST part of Fielding's dissertation relies on describing the web as if every part of its design, say the client/server relationship, was designed, intended and required for the web to be what it is. |
18:23 |
|
jsys |
pdurbin: HTTP2 kind of changes some of THOSE assumptions already |
18:24 |
|
jsys |
pdurbin: we have a single persistent connection where the server can push resources before the client asks for them and what not |
18:25 |
|
jsys |
The relationship becomes more even footed |
18:25 |
|
jsys |
Who knows maybe HTTP3 will finally represent the Actor model properly like Alan Kay told us decades ago |
18:26 |
|
pdurbin |
heh |
18:30 |
|
jsys |
BTW why is no one questioning why the most successful part of the web - HTML, doesn't even support DELETE and PUT? |
18:31 |
|
jsys |
Isn't this kind of very telling? |
18:31 |
|
jsys |
Maybe PUT and DELETE aren't that important about the web hmm :P? |
18:31 |
|
jsys |
And PATCH |
18:32 |
|
jsys |
"give me stuff and take stuff" = the HTML web |
18:32 |
|
pdurbin |
confused. HTML is just markup |
18:32 |
|
jsys |
pdurbin: it's not just markup. When you have a form and click submit, the browser generates a request |
18:33 |
|
jsys |
pdurbin: it's how the web's been working forever until we started using JavaScript for everything |
18:34 |
|
pdurbin |
but it's HTTP that supports GET and DELETE, not HTML |
18:34 |
|
jsys |
pdurbin: my point is the reason we're talking about HTTP is HTML and HTML browsers. And they've only felt the need to implement GET and POST. |
18:35 |
|
jsys |
pdurbin: so why are REST evangelist insisting we use PATCH PUT and DELETE |
18:36 |
|
pdurbin |
jsys: it's like you're saying browsers don't support DELETE, which is nonsense. but keep going :) |
18:36 |
|
jsys |
pdurbin: it's kind of assumed it's important |
18:36 |
|
jsys |
pdurbin: but it's hanging midair |
18:36 |
|
jsys |
pdurbin: how do you send a DELETE request via a browser, aside from handcrafting an HTTP request via JAvaScript. |
18:36 |
|
jsys |
pdurbin: tell me |
18:37 |
|
trygvis |
pdurbin: good luck with that one! |
18:37 |
|
* pdurbin |
is still chewing on it |
18:37 |
|
pdurbin |
:) |
18:38 |
|
whartung |
Webapps != REST |
18:38 |
|
pdurbin |
typically I use curl for DELETE :) |
18:38 |
|
jsys |
pdurbin: :P |
18:38 |
|
jsys |
I have a theory why HTML has only get and post. |
18:38 |
|
whartung |
as to why modern HTML doesn't support random verbs, I dunno. They probably gave up when folks gave up submitting forms for JS everything. |
18:39 |
|
jsys |
Because the distinction between idempotent, and not idempotent and resource deletion versus modification or creation is in fact not interesting enough at the protocol level |
18:39 |
|
jsys |
What's important is nulipotent read vs "some-kind-of-potent" write |
18:40 |
|
jsys |
Also known as the Command-Query separation |
18:40 |
|
jsys |
GET is query and POST is command |
18:40 |
|
jsys |
It doesn't matter what the command does as it's application level concern, a proxy can't just "guess" what happens after post/put |
18:40 |
|
jsys |
It's not in position to do that. |
18:40 |
|
jsys |
A proxy is in position to cache GET but that's it |
18:41 |
|
jsys |
So PUT DELETE PATCH POST are all the same - commands. |
18:41 |
|
whartung |
that's what the idempotency "guarantee" does, it informs the proxy what it can and can't do. |
18:41 |
|
jsys |
whartung: so what does the proxy do with idempotency? |
18:41 |
|
whartung |
it "knows" it can "safely" retry an idempotent request |
18:41 |
|
jsys |
whartung: if a request fails it'll just keep sending it repeatedly? the client might be gone until then; the transaction is canceled |
18:42 |
|
whartung |
maybe, maybe not. If it's a caching proxy, it may simply not care if the client is there anymore for that point in time. |
18:42 |
|
whartung |
The point is that it provides information that intervening infrastrcuture can use to do interesting things rather than simply shut everything down cold. |
18:42 |
|
|
fumanchu joined #rest |
18:43 |
|
jsys |
whartung: HTTP assumes a contract where you send a request and get back a response. |
18:43 |
|
jsys |
whartung: is a proxy has to retry PUT it means the client is not retrying it |
18:43 |
|
jsys |
whartung: so in fact that's quite pointless to take the initiative for a request that the client has given up on |
18:44 |
|
jsys |
whartung: imagine we have a client connecting to a server through 4 proxies. |
18:44 |
|
jsys |
whartung: imagine the hilarious situation is a responce not coming and the client and all 4 proxies retrying for a total of 5 simultaneous retries |
18:44 |
|
jsys |
whartung: is it helping? Not quite |
18:44 |
|
whartung |
the client can be trying the PUT, the proxy blocks the client, while it tries the downstream server. The proxy decides after it learns the cat kicked the cable out that it wants to try again, while still blocking the client, since perhaps it detected this within the timeout window given the client. |
18:45 |
|
whartung |
the client doesn't even know the retry is happening. |
18:46 |
|
jsys |
whartung: how about this |
18:46 |
|
jsys |
whartung: when implementing POST and you want idempotency you can put it at the app-level and the proxies can just retry whenever they want |
18:46 |
|
jsys |
whartung: did I just make things so simple :P? |
18:47 |
|
whartung |
Why have verbs at all? Semantics simply complicate everything. |
18:47 |
|
jsys |
whartung: the separation of command-query is meaningful. |
18:47 |
|
jsys |
whartung: you can cache a query, but... no one caches a command, it makes no sense |
18:47 |
|
jsys |
whartung: but idempotency, while an important concept might not be so important to be at the protocol level. |
18:48 |
|
jsys |
whartung: I mean honestly when is it that you do NOT what idempotency? |
18:48 |
|
jsys |
Ideally you always want it right |
18:48 |
|
jsys |
It's a nice thing to have |
18:48 |
|
whartung |
it's simply not applicable or practical all of the time. That's just simple truth. |
18:48 |
|
jsys |
Of course. |
18:49 |
|
jsys |
But then we can have one command which is assumed will be idempotent most of the time, except in cases where it can't. |
18:49 |
|
jsys |
And then the server can deal with the aftermath |
18:49 |
|
jsys |
whartung: for example we can post to grab a new ID and then send a post with the content for that ID. The first is not idempotent, but it doesn't matter, it's just an ID generator. The second is idempotent |
18:49 |
|
whartung |
or we can work with the semantics given in the specifications. "idempotency most of the time" is no guarantee whatsoever. |
18:49 |
|
jsys |
whartung: problem solved? |
18:50 |
|
jsys |
whartung: it doesn't explain why we have no PUT in web forms, but ok I'll grant you that idempotency has some utility |
18:51 |
|
jsys |
whartung: what about PATCH |
18:51 |
|
jsys |
Semantically PATCH and PUT as idempotent |
18:51 |
|
jsys |
are* |
18:51 |
|
whartung |
I don't know what patch is, I haven't looked at it in detail. |
18:51 |
|
jsys |
The difference is... entirely subjective. Putting a whole resource or patching a part of it |
18:51 |
|
jsys |
Ok |
18:51 |
|
jsys |
What about DELETE |
18:52 |
|
jsys |
Why is that one important |
18:52 |
|
jsys |
Maybe to complete the CRUD matrix :P |
18:52 |
|
jsys |
A proxy can erase a resource from its cache or yadda yadda. Except it can't really. |
18:52 |
|
whartung |
idempotency is simply a semantic that the infrastructure can leverage. It's a protocol guarantee that arguably doesn't even apply to the application, as it's not an application semantic. |
18:53 |
|
jsys |
You can delete a resource and someone might create it again. |
18:53 |
|
jsys |
Or you may delete it and it's still there in some form. |
18:53 |
|
jsys |
Resources are not literally files in a file system |
18:54 |
|
jsys |
whartung: that's not really true though. You can easily name something "PUT" and let it have non-idempotent effects on your app. The app should ALSO support it. |
18:54 |
|
jsys |
whartung: PUT is at best a flag "this is idempotent at the app level everyone!" |
18:55 |
|
whartung |
no, it's idempotent at the protocol level. The application simply needs to realize that and understand the ramifactions of that characteristic. |
18:55 |
|
whartung |
if the app doesn't want that capability, then it shouldn't use PUT. |
18:55 |
|
jsys |
whartung: the protocol doesn't manage the resource |
18:55 |
|
jsys |
whartung: it just represents aspects of it |
18:55 |
|
whartung |
but idemptoency is a protocol aspect. |
18:56 |
|
jsys |
I see it as a flag. Just like GET is a flag "imma gonna serve a representation and do nothing else" |
18:56 |
|
jsys |
It's an aspect of the request that is implemented at the application level and communicated in the HTTP protocol |
18:57 |
|
jsys |
A marker |
18:57 |
|
jsys |
*Srhug* |
18:57 |
|
whartung |
see it how you like, but simply understand the the application has not choice on how the protocol treats it. You can assume PUT is not idempotent, but you are in for a rude shock when a duplicate request arrives. |
18:57 |
|
jsys |
whartung: sure |
19:00 |
|
jsys |
whartung: or we can just use POST for everything and avoid the problem entirely |
19:01 |
|
whartung |
of course |
19:02 |
|
jsys |
whartung: I still have problems with communicating idempotency. Let's say we have an event sourced blog. |
19:02 |
|
jsys |
whartung: PUT /blog-post-url { content } |
19:02 |
|
jsys |
whartung: is it ok for a proxy to resend this to me a thousand times? It's idempotent but it's flooding my event log. |
19:02 |
|
jsys |
:P |
19:02 |
|
whartung |
you don't have to prefix my name to every line…we're low enough traffic that I think we can follow the thread :) |
19:03 |
|
jsys |
ok :P |
19:03 |
|
whartung |
is it "ok"? no, it sucks. but it's "legal". |
19:03 |
|
jsys |
Idempotency has nuances it turns out |
19:03 |
|
jsys |
It's not absolute. |
19:03 |
|
jsys |
So in a way we could do without it. |
19:03 |
|
jsys |
:P |
19:04 |
|
jsys |
I mean at the protocol level |
19:09 |
|
whartung |
I'm not on the standard committee. I've been on those things in the past. They're generally awful experiences. It's far easier to simply cope with the results than mire myself in the process. They tend to be wide reaching encompassing broad experiences far bigger than my little bit of the internet. Feel free to chime in your concerns with the HTTP protocol next time it comes up for review. |
19:10 |
|
jsys |
whartung: :) |
19:10 |
|
jsys |
I think those things will always be messy as any public widely used standard is |
19:10 |
|
whartung |
si |
19:14 |
|
|
autrilla_ joined #rest |
19:21 |
|
trygvis |
does anyone know of a format / media type specialized for sensor data? IoT type of sensors |
19:22 |
|
whartung |
I haven't heard of anything. Do you think it needs something specialized? |
19:22 |
|
trygvis |
dunno, but I'm not sure how I want to design it so I was hoping to look at prior art |
19:23 |
|
whartung |
grab a machete and blaze away :) |
19:23 |
|
trygvis |
I'm sure someone has though long and hard about the problems that arise from this kind of data |
19:26 |
|
whartung |
hard to say, I think there's a lot to be said to tying it to the sensor type, or even the application itself rather than something higher level. I know there are standards for, say, medical equipment which have some particular use cases, but their use case of "reporting temperature" is probably different than, say, an industrial control scenario, or using your Nest at your house. |
19:27 |
|
whartung |
or, on the other hand, it's bone stupid. "thing": thingid, "date": <date of measure>, "temperature": 72, "units": 'F' |
19:28 |
|
whartung |
/me shrugs |
19:29 |
|
|
cigarshark joined #rest |
19:29 |
|
trygvis |
yes, definitely |
19:30 |
|
trygvis |
currently I'm sending lines that look like that, but the files get big when I collect the data |
19:30 |
|
whartung |
I thnk most sensor standards are very tightly bound to their domain (car sensors using micro controllers and CAN buses vs Medical equipment shoving HL7 via TCP) |
19:30 |
|
trygvis |
so one issue is to find a format that compresses that kind of data |
19:30 |
|
whartung |
Gzip! :D |
19:31 |
|
trygvis |
nah, it's not nearly as good as it could be |
19:31 |
|
whartung |
no it's not |
19:32 |
|
whartung |
ask jsys to convert your data in to the minimum number of bits, and shift and mask your way to glory. Don't forget the check digit! |
19:32 |
|
trygvis |
some of my data has constant or near constant fields, that should be compressed to a bit or byte |
19:32 |
|
whartung |
si |
19:32 |
|
trygvis |
like thing-id :) |
19:32 |
|
whartung |
or 'temperature' |
19:32 |
|
whartung |
'caloric differential rating' :D |
19:32 |
|
trygvis |
yes, but that is probably the most variable one :) |
19:33 |
|
whartung |
huffman encoding compresses that kind of stuff really well |
19:33 |
|
trygvis |
I'm measuring soil moisture, but my sensor isn't very good so it changes almost every sample :) |
19:33 |
|
whartung |
since you have a very limited symbol set. |
19:34 |
|
whartung |
yea, but you're getting discrete values, most compression like streams, so there's that issue |
19:34 |
|
trygvis |
hm, I'll look at that. I think simple run-length encoding should be useful too |
19:34 |
|
trygvis |
nah, I'll compress them daily or something |
19:34 |
|
whartung |
ok |
19:35 |
|
trygvis |
the devices send data over serial or bluetooth to an mqtt hub which distributes the data |
19:35 |
|
jsys |
You laugh at jsys, but jsys would like to note HTTP2 is packing bits like there's no tomorrow :P |
19:35 |
|
whartung |
huffman encoding is basic dictionary encoding, rght? grab the symbols up, get the popular ones, key them in the index, have an index byte (like 0-127 is an indice in to the index, 128 means "here comes an excpetion", andyou can use whatever bit length is appropriate.) |
19:35 |
|
whartung |
no, I laugh with jsys |
19:36 |
|
jsys |
jsys is satisfied |
19:36 |
|
|
vanHoesel joined #rest |
19:37 |
|
trygvis |
yes. I think I need to be able to introduce new items into the index mid-stream |
19:37 |
|
trygvis |
useful if the firmware is upgraded and the device get a new data source |
19:37 |
|
trygvis |
all doable, but I would think that someone had done this before |
19:38 |
|
whartung |
yea, that's what gzip does effectively, it continues to refresh and update the dictionary as you go. (not sayin use gzip, just saying the fundamentals of how it works) |
19:39 |
|
jsys |
Actually I should invent some form of "SimpleREST" with just GET and POST, and out of band information allowed for resources |
19:39 |
|
jsys |
I'm sure if I give it a name, the hype will start :P |
19:39 |
|
whartung |
if you're not going to have more that 256 property names, you can go a long way with a simple byte. |
19:40 |
|
whartung |
you can look at how unicode is encoded, but it's byte level, not bit level. |
19:40 |
|
trygvis |
yes, for the name. but I also need a dictionary for values |
19:40 |
|
whartung |
the dictionary can be hard coded in the media type, right? no need to send it every time. |
19:41 |
|
trygvis |
hm, no, I can get new keys and values all the time |
19:41 |
|
trygvis |
I guess I could hard code some keys and possibly values like http2 does for certain headers |
19:42 |
|
whartung |
but you have to agree on those keys at some point, that's what the "expansion space" is for in the "unused bits/values" section. "Reserved" |
19:43 |
|
jsys |
trygvis, whartung I've done this for message exchange between services (over TCP) on connection they negotiate protocol and the protocol includes the version of the dictionary for common keys and values in the message |
19:43 |
|
jsys |
So one can easily version the dictionary and upgrade it |
19:43 |
|
jsys |
But I've gotten a lot of value from a static hand-curated dictionary in my case. |
19:43 |
|
jsys |
You can instantly use it so no need for the connection to stay open for a long time in order to "collect a dictionary" |
19:43 |
|
whartung |
100-200 keys is really a LOT of different values. |
19:44 |
|
jsys |
You also don't have to guess how common a value is, in order to put it in a dictionary |
19:44 |
|
jsys |
whartung: I use varint style compression where the most common words have lower indices |
19:44 |
|
whartung |
right |
19:45 |
|
whartung |
varint is an int that is only as big (in bytes) as it needs to be, right? |
19:45 |
|
whartung |
like, 5 bytes for a full long? something like that? |
19:45 |
|
|
Mxyzpltk joined #rest |
19:46 |
|
whartung |
0-127 is one byte, 128-??? is two bytes (because of the hi bit set), etc.? |
19:46 |
|
jsys |
whartung: yes, basically you use 7 bits and when you trip the 8th bit, another byte comes (7 more bits + 1 more trip byte) |
19:46 |
|
whartung |
yea k |
19:46 |
|
whartung |
that's what I thought |
19:46 |
|
jsys |
the best way to compile a static dictionary is actually by profiling your services and analyzing after the fact which keys are most common |
19:47 |
|
jsys |
Not always applicable but much easier to analyze this out of band. |
19:47 |
|
whartung |
si |
19:49 |
|
whartung |
trygvis: it's really an issue of whether you want to dig in to "bitstreams" vs simply byte streams. Whether that work is worth your time. |
19:51 |
|
|
jcromartie joined #rest |
19:54 |
|
|
shrink0r joined #rest |
19:54 |
|
jsys |
trygvis: dunno if this is of value to you to say, but when I design some specific protocol, I start with the lowest common denominator (usually JSON dictionaries) because they are flexible, and make sure the service/client can understand that. Then I add an "upgrade negotiation" which packs common bits into binary data while reserving exceptions (e |
19:54 |
|
jsys |
xtensibility) to drop back to JSON for parts of the message |
19:54 |
|
jsys |
This way I technically have the flexibiilty of JSON without the baggage of JSON |
19:55 |
|
jsys |
And the binary format is just a "representation" of a common part of a message. And not THE message. |
19:55 |
|
whartung |
all the friendliness of a binary protocol with all the bloat of a text based one! :D |
19:55 |
|
jsys |
Which would really calcify a protocol and make hard to extend |
19:55 |
|
jsys |
whartung: I think of it as "JIT binary protocol": I use bit packing for the "data hotspots" and still hve the flexibility of an interpreter for the rest |
19:56 |
|
whartung |
MIME-TOO |
19:56 |
|
jsys |
The negotiation part is important because you can drop to older and older version os fht ebinary protocol and ultimately JSON and still operate |
19:56 |
|
whartung |
si |
19:57 |
|
trygvis |
I think byte streams is fine, this isn't a format for the first mile :) |
19:57 |
|
trygvis |
the sensors will ship data in their own format depending on the link type and power available |
19:57 |
|
whartung |
that makes it much easier. |
19:57 |
|
jsys |
It's kind of unfortunate the JSON spec is coupled with its text representation |
19:58 |
|
jsys |
It'd be much better if text was but one representation of an abstract model |
19:58 |
|
trygvis |
there is bson which is kinda nice but also kinda unspecified |
19:58 |
|
trygvis |
but it's only a binary version (with some snacks) of json, no smarts across documents |
19:58 |
|
jsys |
trygvis: it more like a cousin to JSON, because not only it's binary, but it's also a different abstract model (more types, somewhat different semantics in places etc.) |
19:58 |
|
trygvis |
I recently discovered json-seq, but that doesn't help much |
19:58 |
|
trygvis |
yeah |
19:59 |
|
jsys |
trygvis: I see it like this, if the abstract model is solid, it means you can just write an adapter in C/Java and have it deserialize to the same object with the same semantics and back. The wire format becomes a detail. |
19:59 |
|
jsys |
But the abstract model is kind of vague for JSON too |
19:59 |
|
jsys |
Especially around numbers and precision and what not |
19:59 |
|
whartung |
well there ya go trygvis. Simply add an extensibility point where a dictionary CAN be included, and then just go with a hard code dictionary that can slowly evovle. That way you don't have to specifiy the dictionary every time, but you can add one later. Add in that that dictionary namea are in BAUDOT (5 bit characters) for extra l33t and geek cred. |
19:59 |
|
trygvis |
not a problem for me |
20:00 |
|
trygvis |
whartung: sweet! |
20:01 |
|
jsys |
BTW JSON is so simple a credit card chip can use it. |
20:02 |
|
jsys |
Kinda weird when you think about it |
20:02 |
|
trygvis |
producing json is not the issue for me, the number of bytes requires is an issue |
20:02 |
|
jsys |
It is. |
20:02 |
|
jsys |
In high volumes mostly though. |
20:02 |
|
jsys |
I kinda didn't understand what kind of sensors trygvis is doing a protocol for |
20:03 |
|
trygvis |
"green" stuff, soil moisture is the one I'm working on now |
20:03 |
|
jsys |
Do you expect to eb a bandwidth bottleneck somewhere or dunno. |
20:04 |
|
trygvis |
nah, not really. but battery lifetime is an issue |
20:04 |
|
jsys |
Hmm point |
20:04 |
|
trygvis |
for those using radio in particular |
20:04 |
|
jsys |
Yeah |
20:04 |
|
whartung |
not good to have the battery die mid-transmission |
20:05 |
|
trygvis |
not a big deal when it comes to soil moisture, and it's often covered by the link layer |
20:05 |
|
trygvis |
bluetooth 4 in my case |
20:05 |
|
trygvis |
and possibly IPv6 on top latetr |
20:05 |
|
|
Left_Turn joined #rest |
20:09 |
|
|
shrink0r_ joined #rest |
20:09 |
|
jsys |
Stuff I said about adaptive protocols would obviously be too heavy for what you do but it's still nice to have that ability to transmit an "unexpected" key as plain text if there's no dictionary index for it |
20:12 |
|
trygvis |
for the BT stuff the characteristic will imply a set of keys so the first packet will have a pre-defined set, but the central aggregation stuff will definitely have to handle unexpected keys. I see that as a major feature |
20:13 |
|
trygvis |
I want to be able to throw all kinds of sensor data at it |
20:59 |
|
|
shrink0r joined #rest |
21:18 |
|
|
_ollie joined #rest |
21:38 |
|
|
Mxyzpltk joined #rest |
21:42 |
|
|
Duqu joined #rest |
21:55 |
|
|
vanHoesel joined #rest |
22:02 |
|
|
shrink0r_ joined #rest |
22:36 |
|
|
jsys joined #rest |
23:44 |
|
|
pezra joined #rest |
23:51 |
|
|
SlippinJimmy joined #rest |