7 ms·

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 w

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

hsn915 5y ago
How is it type safe? Type safety is worse for http calls because you literlly have no idea at compile time what the data will be. Where as, when all the data is in your repository, you can verify the data matches what you expect. 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.
- schoen 5y ago
  Above I suggested that reducing space could sometimes be relevant -- I think interactive maps are a very familiar example, although offline maps are great for privacy and for being able to use them in the wilderness. 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).
- friendly_chap 5y ago
  Have a look at the Go clients for example. There are proper type safe clients for each API generated form our protobuf definitions. > 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.
  - schoen 5y ago
    > We promise we will return data as per API spec ;) 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". :-)
  - hsn915 5y ago
    > We promise we will return data as per API spec ;) ok sure, but that does not mean that "type safety" is an advantage of using your API.

hsn915 5y ago

How is it type safe? Type safety is worse for http calls because you literlly have no idea at compile time what the data will be. Where as, when all the data is in your repository, you can verify the data matches what you expect. 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.

schoen 5y ago
Above I suggested that reducing space could sometimes be relevant -- I think interactive maps are a very familiar example, although offline maps are great for privacy and for being able to use them in the wilderness. 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).
friendly_chap 5y ago
Have a look at the Go clients for example. There are proper type safe clients for each API generated form our protobuf definitions. > 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.
- schoen 5y ago
  > We promise we will return data as per API spec ;) 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". :-)
- hsn915 5y ago
  > We promise we will return data as per API spec ;) ok sure, but that does not mean that "type safety" is an advantage of using your API.