On Fri, Jul 23, 2010 at 8:46 PM, Luciano Resende <[email protected]> wrote: > On Fri, Jul 23, 2010 at 12:42 AM, ant elder <[email protected]> wrote: >> On Sun, Jul 11, 2010 at 2:13 AM, Luciano Resende <[email protected]> >> wrote: >>> Currently, the REST Binding allows configuring multiple wireFormats >>> that defines the payload format. In this scenario, the client/server >>> communication semantics are exactly the same independent of what is >>> being sent over the wire (JSON, XML, etc). >>> >>> For other HTTP Based technologies, such ATOM, etc, which have their >>> own specification which define particular client/server communication >>> semantics; we have been creating specific bindings (e.g. >>> binding.atom). >>> >>> How people think we should handle these types of bindings ? >>> >>> 1) continue with specific bindings for things like ATOM, etc >>> 2) Investigate the possibility to have some kind of map between >>> wireFormat.ATOM to Binding.ATOM >>> 3) Incorporate these type of bindings as wireFormats within the REST Binding >>> >>> >>> Thoughts ? >>> >> >> IMHO binding.rest should only do REST type things and non-REST would >> be better in either binding.http or individual bindings. For the http >> based protocols it seems like a reasonable idea to do them as >> binding.http with wireFormats instead of individual bindings then all >> the http processing type things such as setting headers, doing >> authentication etc can be done in one place so the function is >> consistent. >> > > When the REST binding was created, a new name was given to avoid any > disruption with people currently using binding.http... that was also > necessary as we didn't really know what direction it would take and if > all features in binding.http would still be supported. Today we do > know that Binding.REST is a superset of Binding.HTTP and I'm not sure > we really want to have two bindings doing kind of same thing (one with > more features then other) >
If the binding is going to be a superset of binding.http then it should be renamed to something other than .rest so that is clear, calling it .rest seems misleading or even oxymoronic. Perhaps i'm missing what you mean, could you give some examples of function it has thats a superset of what an http binding could do? Going back to your original question; i think we should only do (3) for things that really work in the REST way, (1) and (2) may both be appropriate if we have a binding.http. ...ant
