[developers] RESTful ERG parsing

[Stephan Oepen]

hi ned,

i am of course very happy to see you interested in the RESTful
interface!  finally, it almost seems like we are looking at an
interface (to our lisp-based back-end) that might also appeal to the
youth of the modern age :-)

still new to the 21st century myself, i had to read up a little about
cross-domain constraints in modern web technology first.  from my
current understanding, i should arguably support both JSONP (which is
convenient for some types of clients and does not require modern
browser support) /and/ CORS (which i interpret as the de-facto
standard of the future)?

CORS appears trivial to support on the server side (all i need to do
is provide the additional header ‘Access-Control-Allow-Origin: *’).
JSONP does not seem very hard to implement either: i would have to
support an optional ‘jsonp’ (or maybe ‘callback’) parameter and return
the JSON response as an argument to the function named by that
parameter.  the main complication on my end, it seems just now, would
be setting the content type served behind the RESTful interface
dynamically, as i understand the JSONP response would have to be of
type ‘application/javascript’.

mike and ned, does the above sound about right to you?  if so, i think
i could provide CORS support immediately.  if that were available, do
you see additional value in also supporting JSONP?

either way, many thanks for sharing your thoughts!  oe


On Tue, Apr 19, 2016 at 3:30 PM, Ned Letcher <ned at nedned.net> wrote:
> Hi Stephan, Mike and all!
>
> In accordance with my previous excitement about an ERG parsing API, I sat
> down to try to write some javascript to consume the API but forgot about the
> cross domain limitation that Mike mentioned:
>
>> How do you feel about cross-domain requests? If you don't mind other web
>> services utilizing your infrastructure for these requests, you could setup
>> CORS (http://enable-cors.org/). Alternatively you can use JSONP (not to be
>> confused with JSPON I mentioned earlier), where you wrap the json object in
>> a client-defined function callback. Of these options, JSONP is the easiest
>> to setup, and I'd be happy to assist.
>
>
> My understanding is that, currently, my code would have to be hosted off
> delph-in.net in order for it to make a successful ajax request to the API.
> It sounds like your intention Stephan was for this resource to be consumed
> by all manner of clients, so I would like to add my endorsement for this
> enhancement. Looking into it briefly, I think Mike is right, in that adding
> JSONP support would be is as simple as adding a new 'jsonp' output target,
> and then wrapping the JSON object to return for this output in a function
> call whose name is the value of the user supplied 'callback' parameter.
> Sounds like Mike has more of a handle on it than I though :)
>
> Cheers,
> Ned
>
>
>
>
>>
>>
>>>
>>>   i think i
>>> will standardize on 3.3 and upwards then, and if and when you get to
>>> adding a client interface to pyDelphin, i will let you find out
>>> whether and how to work around Unicode limitations in 2.x :-).
>>
>>
>> Ok. Last night I put together a MRS-JSON serializer-deserializer, based on
>> our discussions. So that part is ready.
>>
>> Regarding unicode: I don't think I have experienced the problem you're
>> describing, but in transport the requests should be encoded byte sequences,
>> whether it's Python 2 or 3. Python 2 often confuses byte strings and unicode
>> (codepoint) strings and operations using both will implicitly up-cast bytes
>> (assuming some default encoding) to unicode. Python 3 makes the division
>> more clear and doesn't implicitly decode bytes, so you might see more errors
>> initially, but in the end it is (I think) more understandable.
>>
>
>
>
> --
> nedned.net