Built for data storage in small personal projects, or mocking an API for development. Advantages are simplicity, interoperability (JSON files, APIs, multiple filesystems) and performance (using the cache system).

The API is based on your JSON files/structure. So, the example below is for CRUD-ing [key1][key2] in file.json. The value (which can be anything) is then added to the body of the request. Moreover, there are helper functions for appending and incrementing values. As a result, the data creates the API.

DELETE/PUT/GET: /api/file/key1/key2/...

no comments (yet)

sorted by: hot top controversial new old
there doesn't seem to be anything here
8 comments in c/selfhosted@lemmy.world view that post
[–] 9 points 10 months ago (6 children)

I think you should make it more clear in your docs that this is wildly insecure and should be restricted to "tinkering" usage only.

That said it seems like a fun project to write.

  • source
  • hideshow 6 child comments
  • [–] [S] 1 point 10 months ago*

    Thanks for checking my project out. In the readme I state it's for 'small personal projects' where you want to get something quickly. However, "widly insecure" seems a bit much? If you use it for storing data that has no privacy (like public blog posts, and their comments)?

  • source
  • parent
  • [–] -1 points 10 months ago (4 children)

    Many api implementations are bare http because security is expected to be handled / wrapped by another technology.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 2 points 10 months ago (3 children)

    "Security" is not just "ssl"...

  • source
  • parent
  • hideshow 3 child comments
  • [–] 0 points 10 months ago (2 children)

    That's true. So is my comment.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 10 months ago (1 child)

    What "other technology" is going to make sure your API doesn't have SQL injection and bad authentication vulnerabilities?

  • source
  • parent
  • hideshow 1 child comment