Cover image for noREST - schema-less REST API

noREST - schema-less REST API

janhommes profile image Jan Hommes ・2 min read

I finally got the courage to publish my side project which I am working on for nearly one year. It's called noREST -> and, as the name implies, the name is referring indirect to noSQL. That's because the concepts are quite similar. Like noSQL, the differentiating is the non-schema layout of noREST. So basically it's an API without a fixed interface. You might question, what do I need an API without an interface for? It's like buying a house without a contract, or not?

You might be right: Having no fixed schema/interface on an API mostly sounds strange and does somehow contradict the intention of an API. APIs are designed to give the programmer an interface that defines how the data needs to be shaped. Like a purchase contract when buying a house: Everything needs to be in place, there are rules and rights that need to be followed and there is a notary who ensures the contract. If something in the contract is invalid the deal will not be signed.

However, even buying a coffee is already a purchase contract. And they mostly follow the same rules: The barista is offering the coffee and you are willing in on the contract by simply stating "Can I get grande latte chocolate whatever thingy". As soon as the exchange of money and "coffee" is done, the deal is closed. No notary, no fixed contract, no signing. Still a valid purchase contract.

The same goes for APIs: Sometimes the need for a simpler and easier contract then traditional schema bounded APIs is a valid use case. Especially when it comes to server-side-rendering or when you simply just scratching an app and want to focus on building the UI first.

That is what noREST is built for. By simply calling npx @norest/cli you get a REST-full server, which follows very simple rules (like buying a coffee). These rules are designed to allow rapid development. One of the core rules is, that there is no schema. Endpoints are defined by so-called index fragments which are simply data itself with a special prefix:

POST /api
   "name": "foo",
   "price": 10,
   "#_products": {}

Is the above data posted to the API, the data is requestable via a GET /api/products simply because the index fragment "#_products": {} is added to it. That way you can store any data to the API and still using it in a RESTfull manner. Like noSQL just for APIs. Simply called noREST.

What most people don't know: noSQL stands for not only SQL. Meaning that it allows more than just querying data. The same goes for noREST. Currently, there is authentication, metadata, references, and WebSocket support out of the box and more is planned as plugins.

If you like the idea, you can see all that in action on the small interactive playground at https://notonly.rest. If you want to dig deeper into noREST, the best way to start is the GitHub page.

Thanks for reading about my little side project. I would be happy to hear your thoughts about this?


Editor guide