Looks useful. I really dislike the "Download Postman and then you will have documentation" approach. Documentation lives on the web, and there are better alternatives to Postman anyway.

https://postwoman.io/ is my fav. Works on browser no need to download an electron app to make requests. VS Code also has a nice extensions too.

I’m curious: what are your top alternatives to Postman?

Insomnia [1] is a good one, it has all the necessary features to navigate REST APIs without the cloud clutter that comes with Postman.

[1] https://insomnia.rest

Paw (https://paw.cloud) is my favourite.

Rested (https://addons.mozilla.org/en-US/firefox/addon/rested/) which run as a browser extension.

cURL, with some bash aliases to help things along.

I prefer this as well.

Rather not go down the road of having examples for every major platform.

restclient.el for emacs

Thanks for the feedback, I agree that the Postman approach may not be the best solution. I'll look into another way to display API docs!

I suggest swagger/openapi.

I'm so excited to finally be able to share this with you!

Pantry is a free cloud storage service that I've been building for the past few weeks. You can use the API to store & retrieve data for you and your users online for free.

Looking forward to seeing what you all think of it, and please feel free to post suggestions or AMA.

Thanks!

What's your data integrity policy like? In particular, what's your privacy policy? What technical measures, if any, prevent misuse of uploaded data?

Great question! Let me get back to you?

You are right, and all of your points are valid. I will definitely be looking into drafting some documents revolving around data integrity and privacy.

As for the prevention of misuse, I've added a data limit per basket and a limit of baskets per Pantry.

If you have any ideas or suggestions - I'm all ears.

Thanks!

How will you pay for it if costs go up?

Great question!

I believe this is a good problem to have, and perhaps one day I'll be lucky enough to face this.

I've spent some time thinking of how to monetize Pantry - perhaps a private tier, something that is more feature-rich?

I shared a free JSON API with parse.com with a bunch of friends to develop a set of FOSS CLI apps we communicated over.

It was all open and fun and funny.

Then parse.com shutdown. https://en.wikipedia.org/wiki/Parse_(platform) -- What started out as fun project for several developers turned into a dead project for us all, which by then had hundreds of users around the world, who were now getting errors instead of fun.

We all used different programming languages, nobody was able to re-engineer all of our clients into a new endpoint/api. My takeaway -- any one of us could have hosted the JSON api, but we made the mistake in thinking we would use a free 3rd party service. That decision killed the project.

One thing I'd express, is many people launch cool things without a monetization plan, become popular largely because their free, and then lose everything they built when they realize to monetize effectively they have to "alter the deal".

Beware of Vadering your project: Figure out what you can charge for early, and never offer it for free.

Duly noted, this was an eye-opener. I suppose I should prioritize this while I still have time.

Time to step away from the keyboard and think about the business side of this project.

Oh, I did add a "BuyMeCoffee" button on the About page, but its more of a donation. - https://www.buymeacoffee.com/imRohan

I’d say don’t over think it and don’t quit your day job. But I also assume you’re not pouring money into this. Stay free as long as you can, it gives you data so build out some usage stats, talk to the highest volume users. Figure out what threshold they become willing to pay and how much. Then, ask them to pay because they might have just lied to you.

Haha, yeah I'm definitely not quitting my day job over this, and you're right about the costs as well - Pantry is fairly cheap to maintain.

I might keep it as a free service for the time being and do some research to see if there's value in a paid tier. Thanks!

- How would you sell me on Pantry vs. AWS S3? (You can use S3 in much the same way ... throwing up JSON at a path and fetching it. The cost some would argue is neglible)

- How do you deal with CORS?

- How do you deal with authentication?

Is this intended to be like the take a penny leave a penny jar? You put stuff here knowing anyone could come and destroy it at any time?

I did not sign up, I am only going off your API docs.

> How would you sell me on Pantry vs. AWS S3?

Is this question really appropriate? The developer is sharing a pro bono offering, where does selling anyone on it against a commercial service even come into play?

It looks like a project that must have been fun to make and could be useful for storing non-sensitive data with very little hassle. Long bucket IDs appear to leave little chance for name collision.

If you are building a piece of software that deals with anything remotely like PII or has specific availability requirements, I sincerely hope this is not something you are seriously considering (otherwise, pardon me, I hope I won’t be your user or customer), starting from the fact that you aren’t paying for it and there is no SLA.

Of course it’s appropriate! From the docs this service doesn’t even meet the “viable” part of MVP! Ok a user can post some json that’s public (no authentication) and doesn’t even work across domains (CORS).

Suppose adding those things and targeting “mobile backend as a service” or even more general “backend as service” there is still a lot to be desired. Like static html, ok you’re competition is Firebase.

How’s Firebase doing these days?

Thanks for the kind words and for understanding where I'm coming from, and my perspective :)

"Sell me on X vs. Y." is a colloquialism. It's just a different way of asking "what are the benefits of X over Y."

We’re talking welcoming a stranger sharing the result of their work with “but what are the benefits of your free solution over megacorp Z’s paid offering Y?”.

That is your interpretation but not my meaning.

Hey, thanks for the feedback.

This is definitely been a learning experience for me, and I'm really not sure what the future holds for the project.

CORS was/is an issue that I've yet to fully figure out, if you have any ideas please share - I'd love to learn.

Authentication is something that I've delebratly avoided as I feel Pantry should not be used to store sensitive data, nor should it be ever used in production. It's for POC's, hackathon projects, and should be used as a development tool for rapid prototyping.

Please let me know if you have any suggestions, and please feel free to submit PR's if you'd like!

Let the user register a site when they create a UUID (Account). You are not storing private data. Let the user make cors request using the UUID as an authorization token. If the website and the UUID match, the server responds with the content.

Hi, found an earlier comment of yours mentioning you changed to being a hotel owner. We make a free hotel PMS -- would you like to get in touch and see how we can make it better for you? https://hoteliera.com/

I've done something similar for some of my students to test restful apis at http://mockrest.com.

It is quite similar to this although you just write your own data on a textarea, and get/post/put/delete to modify it.. Then you can copy-paste the result json from the backend to a text file or something like that..

It dynamically finds your objects (even nested ones) and you can CRUD them..

Is the pantry GUID the only form of security for all objects? Can this be rotated should it be compromised?

Great question!

Currently, the PantryID (uuidv4) is the only form of security, I am thinking that in a future release perhaps another form of authorization may be required.

Do you have any suggestions - I'm all ears!

Yeah, I imagine this is okay for testing, since UUIDs are fairly impossible to guess, however, you probably want a slightly more elaborate "authenticated session" based structure to ensure someone malicious who has obtained the UUID does not have an unlimited time window to exploit it.

I had this exact idea the other day with a tiny twist. This is rad. Might use it for my little project. TY

Thanks for the kind words, this means a lot to me :)

I hope you find some good use out of Pantry, very excited to see what you come up with!

Very cool! I was looking for something like this about a month ago when I was building an example web application for firmware developers. Firmware engineers aren't expected to know anything about databases and usually don't, so I just wanted some dumb JSON store in the cloud that didn't need any provisioning.

In the end, I went with Heroku and it's included PostgreSQL offering and stomached the complexity, but along the way I found https://jsonbox.io/, which I thought was neat and seems very similar.

Thanks for the kind words! You're essentially the use-case that I had in mind when I was developing Pantry!

How did your project turn out btw, did the firmware developers get their mind blown by web tech?

Project/Article turned out very well. It was more of a proof of concept with the code open-sourced so people can have something to start with to track firmware binary sizes on a commit-by-commit basis.

https://interrupt.memfault.com/blog/code-size-deltas

Unsure if their minds were blown, but I at least know that mine would have been if I showed it to myself a couple of years ago. During that time, I had never touched databases, migration files, or devops in general. Now that's changed, but I still try put myself in those shoes.

Wow, this is pretty neat!

I have some friends who are into firmware development so ill pass this along.

Love how verbose your docs are - good stuff!

What are the rate and size limits for the API? Also what is the data retention (how long before you delete the buckets)?

Great question!

Size limits are pretty small, a little over 1mb per basket.

As for data retention, the account has a TTL of 5 days, baskets 3. Any activity on the account/bucket will result in the TTL's being refreshed.

Some API requests get a JSON response (Retrieve Account, Get Basket). Others get a plain text response (Create Account, Create Basket). Errors seem to get an HTTP response with an HTML page. Is this documented anywhere?

Ouch that is confusing. And no, I haven't added these details to documentation yet. This is a bit of an issue at the moment, having everything return in one format is the right thing to do.

Will be addressing this in the near future - thanks!

The Retrieve Account API seems to always return an empty baskets array, even if baskets with data exit. fyi,

Oh yeah, this definitely needs to be addressed and is currently an active issue on GitHub. Thanks for reporting!

How do you prevent someone from spamming you and filling your cache up with abusive documents?

I have a basic rate limiting implemented, but nothing that prevents people from really abusing the storage platform.

Accounts and Baskets that are stale are automatically removed, however, so there's that?

Will look into alternative methods of spam prevention - any tips?

I love the graphics and web design! It looks like a simple service, and more alternatives in the space are welcome!

Full-disclosure, I also develop a "competing" (if you can call it that) service: https://kvdb.io - my landing page isn't as nice. Our buckets offer some atomic operations on keys and Lua-based scripting (you can spit out arbitrary text or HTML and handle basic GET/POST requests with parameter parsing), which might be useful for prototyping.

You should figure out how to sustain this kind of service on $FREE. In my experience, I've found a lot of people sign up but don't use it for anything serious. One of my first customers signed up and demanded a refund immediately after he discovered "oh, your simple key-value store doesn't support SQL queries?"

Good luck!

Is this a monetized redis?

I’m currently building something very similar but with a usage based payment system (not implemented yet). https://quickstash.io

Very exciting, I really like your website - especially the API docs!

Awesome work!

Hey thanks! I guess we'll have some friendly competition. :)

Looking forward to it!

A mozilla alternative is Kinto

* Used e.g. for profiles sync

* Deploys to heroku - 1 click

https://www.kinto-storage.org/

The API docs page is only scrollable if your mouse is over the docs text. If you try to scroll on either side nothing happens (OSX, Chrome Canary).

Ouff - good catch!

Will fix soon, thanks!

Where are you sourcing the clip art? You are the 3rd startup I have seen with the zen woman in the past week.

I found these great illustrations here - https://www.opendoodles.com/

They're really well done!