🐫 API wrapper for Shaarli exposing pinboard.in/api. Zero-config, drop-in, single-file CGI deployment. https://demo.mro.name/shaarli-v0.41b/pin4sha.cgi

Marcus Rohrmoser 929e452db8 testdata 2 years ago
bin 63edb6f88f λ 🐫 2 years ago
lib 63edb6f88f λ 🐫 2 years ago
pinboard.in 63edb6f88f λ 🐫 2 years ago
test 63edb6f88f λ 🐫 2 years ago
.gitattributes 929e452db8 testdata 2 years ago
.gitignore 63edb6f88f λ 🐫 2 years ago
.travis.yml 63edb6f88f λ 🐫 2 years ago
LICENSE 653ca6e072 Initial commit 6 years ago
Makefile 63edb6f88f λ 🐫 2 years ago
README.md 63edb6f88f λ 🐫 2 years ago
doap.rdf 63edb6f88f λ 🐫 2 years ago
post.msc 8daa236850 🚀. 3 years ago
post.png 8daa236850 🚀. 3 years ago

README.md

pinboard.in.cgi

The natural API for shaarli.

Why?

The wish to have an API goes back to the early days.

And because shaarli started as a personal, minimal, delicious clone, using a minimal subset of just that very API seems natural to me. pinboard.in prooves the API is not only seasoned and mature, but also still up the job today.

Also another project of mine, ShaarliOS needs a drop-in API compatibility layer for a wide range of shaarlis out in the wild.

How?

You find a single, statically linked, zero-dependencies (🐫 Ocaml) binary which is both a

  1. cgi to drop into your shaarli php webapplication next to index.php – as the API endpoint,
  2. commandline client to any shaarli out there, mostly for debugging and compatibility-testing purposes.

post flow

Compatibility

All shaarlis from the old ages until spring 2020 (v0.11.1).

All systems 🐫 Ocaml can produce binaries for.

Just the delicious API calls in pinboard.in/v1/openapi.yaml

Design Goals

Quality very good good normal irrelevant
Functionality ×
Reliability ×
Usability ×
Efficiency ×
Changeability ×
Portability ×