greptilian logo

IRC log for #rest, 2015-03-06

https://trygvis.io/rest-wiki/

| Channels | #rest index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary

All times shown according to UTC.

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

| Channels | #rest index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary

https://trygvis.io/rest-wiki/