Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Show HN: JSONP - enable cross-domain requests to any JSON API (w/ AJAX) (jit.su)
51 points by aidanfeldman on May 12, 2012 | hide | past | favorite | 33 comments


How reliable is this service trying to be?

While I think it is a cool service if a person is just hacking around, it is not something I would use with any revenue generating project.


feel free to download the source to reimplement or host your own


I just recently did something similar: https://github.com/jostylr/cors-lite

It was to give a JSON API for http://bootswatch.com

It would be easy enough for anyone to host it on something like nodester.com or cloudfoundry.com and have it just for your own JSON data.


I simply have to commend your choice of project title here.



cool service, I hope it remains up so we can depend on it.

Currently you can accomplish the same thing using Yahoo's YQL, if you'd rather trust a big company to stay up. Here's an example: http://y.ahoo.it/b7rnO

I'm using it on my website to parse my project's history.json file: http://ruhoh.com/latest-updates/, check the source on that to see how it works.

Be warned that YQL transforms arrays containing one element into strings =/, terrible I know but it works.


Trust Yahoo! to keep a service running?



And in case anyone is wondering, that's how the Easier option is implemented (CORS), whereas the Easy option is just JSONP.

OP could probably make it more explicit since it's not just a JSONP service, but also a CORS relay.


I wanted to use CORS a while ago but without Opera and IE 6 and 7 supporting it, it'll take a while until it will be an alternative to JASONP.


irrelevant really- you can't set the CORS header on a remote API you don't own.


that's kind of the point. CORS just tells the browser to block the response, so this proxies the request and simply changes the headers to avoid that restriction.


More functional too, but it requires complicity from the remote server.


JSONP requires complicity from the remote server too


I tried this once with a proxy script and it eventually lead to inconsistencies. I've settled on using an apache reverse proxy when I need to do cross-domain json posts (typically for dev work).Just put this in your vhost config

ProxyPass /api/ http://destination.com/api/ ProxyPassReverse /api/ http://destination.com/api/


One things these services often lack is the ability to change the user agent before making the request. For awhile, if one wanted to make use of Pinterest's API, they would just need to change the user agent to mimic the iPhone app. (Recently Pinterest has made using the API more difficult so such a technique is no longer sufficient.)


[deleted]


I hope you meant, "If you want to pass any secure information that would require HTTPS you can't use it.". POST does not make anything "more secure". (And JSONP should work cross site with HTTPS anyway)

Of course if you want to do multipart submissions or anything too long to fit in a url, you'll be needing POST anyway.


[deleted]


As a general note, GET and POST requests expose their parameters with equal visibility. It's just that the browser makes it more obvious what your GET parameters are


I thought this was going to be about https://github.com/jaubourg/jquery-jsonp but apparently not. I wouldn't trust it, personally, though I see its uses.


Well, based on the comments it sounds like you've exposed a need. People want it to be stable and don't seem comfortable with the idea of it being your hobby. Make them pay for it before someone else decides to.


point taken. as long as nodejitsu provides free hosting, though, im happy to keep it free.


Maybe you could make a signup with Stripe or Paypal or something so that people could pay $5 or $10 per month to use it.. that way you would have enough money to at least pay for the server(s) and a reason to maintain it and come up with a way for it to automatically scale.

I mean do you have something like a load balancer or proxy or something that will allow it to scale horizontally in case a few people really take advantage or it becomes popular?

It seems like leaving it totally free would probably end up with it just not being worthwhile to maintain.. but if there is a little money going in and at least one well-known service starts using it then I would totally consider using it.


It was quick for me to make and it doesn't really require maintenance - feel free to donate to the EFF in honor of the project.

In terms of scalability, the app is doing very little processing so it's really just a matter of how many concurrent connections Node can handle in & out, but I've read it's capable of hundreds of thousands or more. Let me know if you are seeing high latency.


It is on nodejitsu so at least portions of the architecture should scale reasonably.



:P sweet


While useful, there are a few implications

1) security

   a) I won't trust you with my API keys

   b) If you get hacked, ANY javascript can be executed on my pages
2) scalability - how much traffics can you handle?

3) I can implement your service with a 3-line PHP script. Why would I use your service?


1a) feel free to download the source and host yourself or write three lines of PHP 1b) not if you use the AJAX version - any response will come in as a string, so just don't eval() 2) the limit is really how many concurrent connections Node can handle, and the answer is "many" 3) It's at least useful for small mashup sites where you can throw up an HTML file with some JS - no server code needed


1a -- you aren't just trusting this site, you are trusting everyone since the API keys can be found within the source.

3 -- it is even simpler than that; the source can be found on github. At the very least, services such as this are useful as you are still developing.

For the viability of a commercial version of this project, I think the biggest question is: why would somebody use this instead of Yahoo's YQL?


no commercial version planned - I threw it up because it was something I was going to use (to build hackerhours.org), and figured it would be useful to others as well


1a) not all API calls require a secret


True, but irrelevant.

Note that I was responding to "I won't trust you with my API keys"

On a tangent, while this is a problem for this particular website, the issue is solveable. (See YQL.)


I think number 3 is the biggest point here, i'm all for solving developer pain points but would be interested to see if there really is a market for this?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: