API design is more of an artform than anything. GraphQL is great when you are perhaps using a noSQL database and the schema is somewhat fluid. However, if you have a relational database - you will get the best results using actual REST APIs.
The best way to think of an APIs design is; why do you need an API in the first place. Creating an API for the sake of having an API is what leads to terrible APIs. Instead design your API for its use case, and if you have multiple use-cases - maybe you need multiple APIs, or a more clever API design that blends well
I am launching a CLI tool this week that allows you to get insights into your Open API specification. It is currently a beta pre-release, but built using Go and pTerm - it was a lot of fun if I am honest!
This shouldn't be charged per API call, you should look at an average of API calls per person - and create a figure 20% above that of what you want to earn.
Alternatively, charge x per month - with a cap of a certain amount of API calls.
The problem with charging per API call is that what do you class as an API call? What happens if a network degrades and the response hangs? Should the end user pay for this? What if they get a 404, or a 401/403? Should they be charged for these?
As your application stores customer data that they own, I could price based on how many records they are storing - not how often they want to access their own data.
Open Source helped me level up my programming skills. Being involved in the open can be cut-throat and bash your confidence, but if you learn from it - it will help you a lot
Yeah the sponsors could maybe be more subtle or obvious that they're sponsors!