<div dir="ltr">I too have been learning more about all this and agree with everything Mike said about CORS/JSONP. There's certainly no need from JSON-P from my perspective if CORS is enabled on the server.<div><br></div><div>Ned</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, 20 Apr 2016 at 07:32 Michael Wayne Goodman <<a href="mailto:goodmami@u.washington.edu">goodmami@u.washington.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Apr 19, 2016 at 1:04 PM Stephan Oepen <<a href="mailto:oe@ifi.uio.no" target="_blank">oe@ifi.uio.no</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[...] mike and ned, does the above sound about right to you? if so, i think</blockquote></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br> i could provide CORS support immediately. if that were available, do<br> you see additional value in also supporting JSONP?<br></blockquote></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><div><br></div><div><div>Your summary looks about right. <span style="line-height:1.5">In my previous message, I thought CORS required a more complicated server configuration, but if it's just a header then it does seem pretty simple. If there's no benefit, then, to using JSON-P besides supporting older IE browsers, we probably don't need it.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">I'm also becoming less fond of JSON-P because it is just a clever use of a cross-site-scripting hack. The client sends the request by dynamically altering their document with a new <script> element whose URL is the request, and it then executes whatever javascript the server sends back. As long as you trust the server, it's fine, but it's still a hack (although it is used by some major services, such as GitHub, Google, etc.).</span></div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Tue, Apr 19, 2016 at 3:30 PM, Ned Letcher <<a href="mailto:ned@nedned.net" target="_blank">ned@nedned.net</a>> wrote:<br></blockquote></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> <span style="line-height:1.5">[...]</span><span style="line-height:1.5"> My understanding is that, currently, my code would have to be hosted off</span></blockquote></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > <a href="http://delph-in.net" rel="noreferrer" target="_blank">delph-in.net</a> in order for it to make a successful ajax request to the API.<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Actually I think it would have to be hosted at the same sub-domain, i.e. <a href="http://erg.delph-in.net" target="_blank">erg.delph-in.net</a>. Subdirectories are ok, though, so <a href="http://erg.delph-in.net/some_application" target="_blank">erg.delph-in.net/some_application</a> would be able to access it, but that means the owner of the subdomain needs to manage all apps that use the API. If the API is meant to be consumed by external apps, CORS or JSON-P is the way to do it.</div><div><br></div></div></div> </blockquote></div>