I can say unequivocally that you should not use /gateway. The weird /* */
doodads are not valid JSON. I'll open a LP bug for deprecating this.
/osrf-gateway-v1 is fine. I see no reason that it won't be around for the
foreseeable future. This interface uses a layer of abstraction one step
above OpenSRF, though. It does not support streaming responses or OpenSRF
sessions (useful for client-driven DB transactions). The beauty of this
interface is that it's simple to test in a browser (as you have found).
/osrf-http-translator provides a lower level OpenSRF API and supports
streaming responses, but its use is no longer encouraged, because the
underlying mechanism (multipart/x-mixed-replace) is deprecated and only
works with our old version of XULRunner. This interface will likely be
deprecated along with the XUL client.
/osrf-websocket-translator (from newer versions of EG/OpenSRF) provides a
standard OpenSRF API, streaming responses, etc. It's new enough, though,
that it's not universally deployed.
WebSockets install docs:
Hope this helps,
On Wed, Sep 21, 2016 at 1:33 AM, Jane Sandberg <sand...@linnbenton.edu>
> Hi all,
> I am trying to make some HTTP calls to opensrf to get some info about
> copy status, and had my eyes on the OpenSRF gateway. However, I found
> two different gateways that seem to behave differently, one at
> http://my-domain.org/gateway and another at
> For a simple call, they seem to work the same:
> For something a little more complex, the /gateway? calls return some
> JSON with weird /*--*/ doodads that I don't really understand:
> My main question: are either of these gateways going away in the
> foreseeable future?
> Another question: are there other "gateways" I should be looking at?
> I'm hoping to make actual OpenSRF calls, rather than an abstraction
> like SuperCat or UnAPI, and would greatly prefer using HTTP calls.
> Thanks in advance for your help and expertise!
> Jane Sandberg
> Electronic Resources Librarian
> Linn-Benton Community College
> sand...@linnbenton.edu / 541-917-4655