I can think of a few:
- type safe clients provided by M3o
- reducing app/webapp/binary space by relying on APIs to get a subset of the content you need
- a web interface to query the data
There are probably a few more, YMMV
- type safe clients provided by M3o
- reducing app/webapp/binary space by relying on APIs to get a subset of the content you need
- a web interface to query the data
There are probably a few more, YMMV
Reudcing space? Really? The data is actually very small. Your npm modules take a lot more space. If anything is really cheap and not worth worrying about, it's disk space.
Even though I don't think that the Quran API will benefit many applications, you could probably envision some, like very tiny embedded systems that don't have even megabytes of spare local storage (but do have some kind of user interface).
> Type safety is worse for http calls because you literlly have no idea at compile time what the data will be.
We promise we will return data as per API spec ;)
> The data is actually very small
For this particular example, I guess you are right.
Our vision is that all APIs will have uniform clients, docs etc, so in aggregate it will provide a very convenient workflow. So instead of downloading a.json and b.xml and c.yaml (if possible at all due to size) and defining data structures yourself, just import our library and you are good to go.
But as I said, YMMV. If it's not your cup of tea, I understand that too.
Unfortunately, I don't think that an assumption about the data that's returned from a web API based on a developer's statement on an online forum is really what's meant by "type safety". :-)
ok sure, but that does not mean that "type safety" is an advantage of using your API.