4 ms·

Really sleek and clean, love the design. A simple but useful product, nice job :) The link to your Twitter on the about page is broken by the way, it should ha

by kbr 9y ago

Really sleek and clean, love the design. A simple but useful product, nice job :) The link to your Twitter on the about page is broken by the way, it should have a protocol.

mr_ali3n 9y ago
Thanks a lot :) P.S Twitter link is now fixed.
- sillysaurus3 9y ago
  Minor bug: The Access URL it generates is invalid. E.g. copying "//jsonbin.io/b/591a7e1cc94cae11ebb443dc" into Chrome's URL bar results in attempting to navigate to "file://jsonbin.io/b/591a7e1cc94cae11ebb443dc", not jsonbin.io/b/591a851ac94cae11ebb4440e.
  - mr_ali3n 9y ago
    Hey, thanks, but it's not a bug :) that's protocol independent URL, it works on HTTP, HTTPS, relative to what your website is running on.
    - sillysaurus3 9y ago
      The primary purpose of your app is to paste some JSON then send someone a URL to access it, right? If a user pastes some JSON, clicks the Access URL text box, presses Command-A Command-C to copy the URL, then pastes it to someone else, that person won't be able to open the URL, because it lacks a "https: prefix. That's probably a bug, whether or not it's an intended feature. It's not something that matters very much, but your users might be slightly annoyed at having to chop off the leading "//" every time they want to copy the URL. I admit I might be missing something obvious, though.
      - mr_ali3n 9y ago
        The primary purpose of the app is to provide free storage and an endpoint to access it in an app. I've also provided a VIEW link beneath the access URL to view it in the browser. If I hard code https:// https:// in front of the access URL, it might fail on non-https URLs and vice versa. Still, I think your concern is legit, will look into it and try to make it more flexible. Thanks for the suggestion bud. Appreciated.
        sillysaurus3 9y ago
        Ah, got it. Nah, you're right, it's obviously meant to be used from within apps, not manually sent to someone else. Just a late-night derp. I didn't expect it to be a service for freely hosting data -- that's pretty cool. I assumed it would return a rate limit error if you tried to use it for anything substantial. (I missed the About link https://jsonbin.io/about https://jsonbin.io/about at the bottom, which explains all this.)
        hdhzy 9y ago
        Yeah it also struck me as something weird and I know about using //. Maybe prepend http/https based on the current page's protocol? So that URL looks like a URL. By the way cool service. I've got an internal JSON store service too and it's super useful for a number of purposes.
        adnanh 9y ago
        it's perfectly okay to load https content on the http urls, just not vice versa

by kbr 9y ago

Really sleek and clean, love the design. A simple but useful product, nice job :) The link to your Twitter on the about page is broken by the way, it should have a protocol.

mr_ali3n 9y ago

Thanks a lot :) P.S Twitter link is now fixed.

sillysaurus3 9y ago
Minor bug: The Access URL it generates is invalid. E.g. copying "//jsonbin.io/b/591a7e1cc94cae11ebb443dc" into Chrome's URL bar results in attempting to navigate to "file://jsonbin.io/b/591a7e1cc94cae11ebb443dc", not jsonbin.io/b/591a851ac94cae11ebb4440e.
- mr_ali3n 9y ago
  Hey, thanks, but it's not a bug :) that's protocol independent URL, it works on HTTP, HTTPS, relative to what your website is running on.
  - sillysaurus3 9y ago
    The primary purpose of your app is to paste some JSON then send someone a URL to access it, right? If a user pastes some JSON, clicks the Access URL text box, presses Command-A Command-C to copy the URL, then pastes it to someone else, that person won't be able to open the URL, because it lacks a "https: prefix. That's probably a bug, whether or not it's an intended feature. It's not something that matters very much, but your users might be slightly annoyed at having to chop off the leading "//" every time they want to copy the URL. I admit I might be missing something obvious, though.
    - mr_ali3n 9y ago
      The primary purpose of the app is to provide free storage and an endpoint to access it in an app. I've also provided a VIEW link beneath the access URL to view it in the browser. If I hard code https:// https:// in front of the access URL, it might fail on non-https URLs and vice versa. Still, I think your concern is legit, will look into it and try to make it more flexible. Thanks for the suggestion bud. Appreciated.
      - sillysaurus3 9y ago
        Ah, got it. Nah, you're right, it's obviously meant to be used from within apps, not manually sent to someone else. Just a late-night derp. I didn't expect it to be a service for freely hosting data -- that's pretty cool. I assumed it would return a rate limit error if you tried to use it for anything substantial. (I missed the About link https://jsonbin.io/about https://jsonbin.io/about at the bottom, which explains all this.)
      - hdhzy 9y ago
        Yeah it also struck me as something weird and I know about using //. Maybe prepend http/https based on the current page's protocol? So that URL looks like a URL. By the way cool service. I've got an internal JSON store service too and it's super useful for a number of purposes.
      - adnanh 9y ago
        it's perfectly okay to load https content on the http urls, just not vice versa