Given there's no one, universal answer to these questions, we'll have to approach it as other languages and platforms have: by making choices.
I'd prefer REST over SOAP, though SOAP ha the advantage of addressing some of your questions below as part of its design. Within REST, I'd prefer JSON over XML as payload format, as I think it would be easier to format and parse in J than the alternatives, and because it can be naively consumed by JavaScript clients. I'd also expect the J application itself to have some say in this: e.g. Which functions to expose using which HTTP verbs, etc. With all that said, I'm hardly an expert in this field. I simply expect that effort put into developing a WS interface will have a higher return in today's environment than an equivalent investment in developing a(nother) implementation of WD. Make sense? -Dan Please excuse typos; composed on a handheld device. On Apr 24, 2013, at 7:52 PM, Greg Borota <[email protected]> wrote: > Web services; which kind to avoid flame wars? I don't think we'd be able to > please everybody even with web services. There are a ton of web service > protocols out there: http://en.wikipedia.org/wiki/Web_service > > What I like most is RESTful web services where you hit a certain URL to get > your data. But then how do you return the data? XML, JSON, HTML? Or you > could probably have different URLs for various types. e.g: > /x/do/j_sentence > /j/do/j_sentence > /h/do/j_sentence > > Then what verb you use? GET? That has a hard limit, of how long it can be, > it's pretty short somewhere about 2k. If you use POST you can post whole > files for processing. You could probably support both. Then the url could > be something else: > /j/post/do etc... > > > > > On Wed, Apr 24, 2013 at 6:14 PM, Dan Bron <[email protected]> wrote: > >> I am thinking of making J interoperability seamless and transparent. It >> will make it easier to embed J on the server-side if we make its interface >> familiar and standard, and in the current state of the IT world, that means >> web services. >> >> A WS interface will allow us to use modern frontend toolkits to write >> user-facing (browser-based) apps, e.g. in Flash, Silverlight, or more >> likely in days to come, HTML5. >> >> It'll also make it easier to offer headless J-based services into IT >> depts, with leas of the usual friction we encounter when presenting a new, >> (extremely) unfamiliar language. >> >> In short, it lets us express ourselves in the way we prefer (i.e. J code) >> while allowing the outside world to interact with us in the way they prefer >> (i.e. web services). >> >> For this to work, I shine the WS interface has to be implemented natively ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
