You have same preferences as I have, concerning REST and JSON. Besides that though I'd still go with a web server to handle the client interaction. Which would take you out of the pure J world.
On Wed, Apr 24, 2013 at 7:08 PM, Dan Bron <[email protected]> wrote: > 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
