tag:blogger.com,1999:blog-22367266.post4105475706837972479..comments2023-07-04T09:16:12.941-04:00Comments on pmuellr: steve vinoski on schemaPatrick Muellerhttp://www.blogger.com/profile/04900886008475308281noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-22367266.post-64918665480776974322008-01-15T22:43:00.000-05:002008-01-15T22:43:00.000-05:00"Pretending"? Pretty harse. I meant no ill will;..."Pretending"? Pretty harse. I meant no ill will; certainly, I didn't intend to intentionally misuse your quotes, nor do I think I actually did. In re-reading my original blog post (I haven't edited it), I certainly agree, now, that the word "schema" is a rather dumb synonym for me to have used for "meta-data" because of it's close association with data (ie, SQL and XML). I don't really distinguish between IDL, annotations, etc; it's all meta-data, and I think I've been referring to it, generically, as schema for a while now. That will change. :-)<BR/><BR/>However, I think the context of the post makes it clear I'm not talking about <B>just</B> data.<BR/><BR/>I'll save a response to your final point on documentation for your next blog post :-)Patrick Muellerhttps://www.blogger.com/profile/04900886008475308281noreply@blogger.comtag:blogger.com,1999:blog-22367266.post-82704362191285181172008-01-15T22:04:00.000-05:002008-01-15T22:04:00.000-05:00Again, my point is that you criticized my posting ...Again, my point is that you criticized my posting based on pretending that it talks about data schema, when in reality it talks only about interface definition languages. And I'll stress again that those are two very very different things. For you to say, "Well, I was talking about metadata, and that's the basis I used to criticize your posting" is questionable, because you're then writing about a whole different topic which I did not cover.<BR/><BR/>I don't mind criticism; in fact I'm quite used to it. I prefer thoughtful objective criticism, since it helps me learn, and of course your posting is indeed thoughtful and objective. But I always prefer criticism that actually targets what I wrote. Putting my name in a blog posting title, and then proceeding to talk about an entirely different topic, even "quoting" me on the topic I didn't write about, hardly seems fair, does it?<BR/><BR/>Now, as for the questions you ask in your latest comment, sorry to say but they're all indeed answered in real life by human-generated and human-readable documentation. Despite the fact that you poo-poo the idea of such documentation, it has to exist in some form, even something as simple as a README file, otherwise nobody can use your service. Having an IDL does absolutely nothing for you in this regard, because nobody can simply take an IDL or a WSDL, read it, and then know precisely how to invoke the service it describes. Yet you seem to claim this is possible. How?<BR/><BR/>I think I'll go blog about this.Unknownhttps://www.blogger.com/profile/05290344629915279127noreply@blogger.comtag:blogger.com,1999:blog-22367266.post-21868430312600934582008-01-15T21:32:00.000-05:002008-01-15T21:32:00.000-05:00JJ,cache validators (if-match, if-modified-since h...JJ,<BR/><BR/>cache validators (if-match, if-modified-since headers) can help identifying 'stale' data, kind of. More of an optimization for non-stale data, but also note these validators can be used on PUT to prevent the multi-update problem (two people updating a resource at the same time).<BR/><BR/>And folks are looking to Atom to provide some of the additional notification issues.<BR/><BR/>And then there's comet as well (persistent client)<BR/><BR/>Of course, none of this is 'realtime', and even comet is a bit of a hack. For something closer to 'realtime' behaviour, look into XMPP.Patrick Muellerhttps://www.blogger.com/profile/04900886008475308281noreply@blogger.comtag:blogger.com,1999:blog-22367266.post-57619264878532192632008-01-15T20:18:00.000-05:002008-01-15T20:18:00.000-05:00BTW, I really meat QoS as in security, transaction...BTW, I really meat QoS as in security, transaction, reliability...Integral ):( Reportinghttps://www.blogger.com/profile/03973062992107742075noreply@blogger.comtag:blogger.com,1999:blog-22367266.post-20903305793394170782008-01-15T20:17:00.000-05:002008-01-15T20:17:00.000-05:00Patrick:yes, I definitely think that REST would be...Patrick:<BR/><BR/>yes, I definitely think that REST would benefit from more metadata. I like the "assembly". Metadata can be used for other things than "generating code", assembling being one of them. <BR/><BR/>IMHO a general resource API should at a minimum contain:<BR/>- QBEs (multiple URI point to the same resource, based on the information you have)<BR/>- inter-actions (bi-directionality is critical here for "assembling")<BR/>- events (express the occurrence of a state)<BR/><BR/>REST has found a really smart way to deal with the QBE section of the interface. The URI space can be extended infinitely without breaking existing relationships.<BR/><BR/>My issue is really the bi-directionality and the events.<BR/><BR/>Events are critical for REST because you get representations of a resource, you need to be informed in some ways when the representation becomes stale.<BR/><BR/>Now, I really think REST can be extended without breaking its benefits.<BR/><BR/>HTTP could be fairly easily extended to deal with events since when a resource passes a representation to a client it also knows which events this representation will subscribe to. All it needs is a subscription end-point on the client. That can't be hard to standardize and implement.<BR/><BR/>In terms of inter-action, there are no problems in "declaring" an inter-action interface (I like to call it a "surface" if you know what I mean) since this is already how the programming model works. Inter-action exist with or without REST. All we need is a standardization a la href to make it work with software agent clients. <BR/><BR/>So overall, I don't really understand all these discussions. Everybody will win to establish a better alignment between REST (the architecture of the web) and programming model (the architecture of enterprise information systems).<BR/><BR/>I am not fully qualified to say if the QoS will result in as much work as WS-*, so I won't argue this point.<BR/><BR/>Cheers,<BR/><BR/>JJ-Integral ):( Reportinghttps://www.blogger.com/profile/03973062992107742075noreply@blogger.comtag:blogger.com,1999:blog-22367266.post-47659521369777735892008-01-15T19:54:00.000-05:002008-01-15T19:54:00.000-05:00JJ,I would not be surprised in the end if you fix ...JJ,<BR/><BR/><I>I would not be surprised in the end if you fix these issues is that you come back on your fit and build something just as complex as WS-*</I><BR/><BR/>Well, if that were to happen, then I guess we might as well have stuck with WS-*, eh?<BR/><BR/>In other words, I don't believe it for a minute. :-) I think providing more meta-data around REST services can provide a lot of value with a low cost. That's really all I'm looking for in REST (at the moment), and it's purely an opt-in action. <BR/><BR/>QoS isn't an issue I've heard about, unless you mean general QoS issues with TCP (and HTTP). There are some common REST patterns which can contain QoS issues like lost connections, etc. <BR/><BR/>w/r/t Erlang and async; given async, you can implement sync, but the opposite is problematic. Erlang excels at multiprocessing via it's (largely) green thread model; single-assignment variables and async fit this model pretty well. For another example, see the Twisted framework for Python.Patrick Muellerhttps://www.blogger.com/profile/04900886008475308281noreply@blogger.comtag:blogger.com,1999:blog-22367266.post-33976677704998348262008-01-15T18:35:00.000-05:002008-01-15T18:35:00.000-05:00Patrick:I like a lot the points that you are makin...Patrick:<BR/><BR/>I like a lot the points that you are making. I think at this point arguing that a uniform interface is enough to interact with a resource is undefendable. Now whether you express this interface with a schema or an IDL, does not really matter. <BR/><BR/>What HTTP gives you is a really cheap:<BR/>- (instance level) directory service (no more look-ups), which can be used up to the correlation level <BR/>- free middleware including great scalable activation capabilities (using web servers) and great intermediation capabilities (such as caching)<BR/><BR/>What is not so great is:<BR/>- the quality of service offered and as people have pointed out, <BR/>- the frameworks are a bit under-developed.<BR/>- asynchronous interactions and events (it's be interesting to see how Steve mix Erlang and HTTP, since Erlang is asynchronous in nature and does not have any "resource" concept and HTTP's sweet spots are just the opposite)<BR/><BR/>I would not be surprised in the end if you fix these issues is that you come back on your fit and build something just as complex as WS-*<BR/><BR/>Cheers,<BR/><BR/>JJ-Integral ):( Reportinghttps://www.blogger.com/profile/03973062992107742075noreply@blogger.comtag:blogger.com,1999:blog-22367266.post-9538018674794523872008-01-15T15:00:00.000-05:002008-01-15T15:00:00.000-05:00There are plenty of people who will claim the data...There are plenty of people who will claim the data doesn't need to be described, or are satisfied with an overly generic description of the data - text/xml, for instance. Or the more extreme view of the only reasonable data for REST is HTML because that's the only format that supports links (add structure w/microformats). So I go defensive when I talk about 'describing services' and include the data as well. Just in case.<BR/><BR/>The world is an opinionated place. :-)<BR/><BR/>w/r/t uniform interface - I think you can often logically consider most of the operations against a resource to deal with some more or less fixed representation of the resource - ie, I can do a PUT on something that I GET. Same representation used for both. And DELETE probably doesn't take a payload in either direction. But what about POST, the wildcard verb of HTTP? What about a resource that doesn't support DELETE - is there some way to identify that in my service implementation to signal the intention that it's not supported? Of course I can presumably issue an OPTIONS on the resource (I think that's how you'd do that) to figure out if DELETE was supported at runtime, but perhaps it would be nice to know this at development time. Last example, there is a common pattern of posting to a collection resource, which causes a 'child' to be created as a separate resource - eg, AtomPub. Wouldn't it be nice to be able to identify such a relationship?<BR/><BR/>Where this gets really hairy is the last example; typically a POST like that might have it's response be a redirect instead of an actual representation. Dealing with descriptions of data flowing over the wire is fairly straight-forward. Dealing with indirection of URLs is a bit harder. How do I 'describe' that?Patrick Muellerhttps://www.blogger.com/profile/04900886008475308281noreply@blogger.comtag:blogger.com,1999:blog-22367266.post-52294490418945400272008-01-15T13:21:00.000-05:002008-01-15T13:21:00.000-05:00I just don't think you can conflate data definitio...I just don't think you can conflate data definition and interface definition to make your argument. The former is clearly required -- I would have hoped it was entirely needless to say that, but I guess not -- and is in fact an important part of REST, in the form of media types or MIME types. The latter, however, is not required for REST because the interface is uniform.Unknownhttps://www.blogger.com/profile/05290344629915279127noreply@blogger.comtag:blogger.com,1999:blog-22367266.post-32844572588670274522008-01-15T11:21:00.000-05:002008-01-15T11:21:00.000-05:00I certainly am not intending to twist your words.I...I certainly am not intending to twist your words.<BR/><BR/>I would certainly agree that there is a lot of confusion, in both terminology, capabilities, and expectations in the IDL / schema arguments for REST. I conflate the two. My concern is meta-data - being able to get a description of my services, and the data they operate on. Which I refer to generically as schema. Bad terminology on my part, I guess - schema is perhaps too closely associated with just data formats. So, my bad; replace my usage of 'schema' with 'meta-data'; am I still twisting your words?<BR/><BR/>If you think schema (presumably data formats) is important, then I'll claim that that's just half the picture - how I can get the data, how I can update the data is similarly important to be able to describe, for the same reasons describing data is important.Patrick Muellerhttps://www.blogger.com/profile/04900886008475308281noreply@blogger.comtag:blogger.com,1999:blog-22367266.post-79303022161038227212008-01-15T09:29:00.000-05:002008-01-15T09:29:00.000-05:00Patrick: schema != interface definition language. ...Patrick: schema != interface definition language. They are not equivalent. My blog post is about interface definition languages, and the word "schema" does not even appear in the post, but your entire criticism of what I wrote is based on twisting it as if it's about schema. You've even used quotes that were specifically directed at interface definition languages and taken them out of context to try to pretend they were written about schema. I fail to see how you can argue against things I did not say.Unknownhttps://www.blogger.com/profile/05290344629915279127noreply@blogger.com