|
|
|
|
|
by buro9
1661 days ago
|
|
Once people use your APIs you cannot trivially modify the bits being used or take things away. A large API likely has complexity, security implications, messy transaction boundaries, etc... keep it small and simple, think of UX of an API, make it intuitive and capable. That's the conservative bit... now the liberal bit. Make clients, make one in Python and look at date parsing, make one in Go and consider struct re-use and how to deal with sets/arrays of things, make one in JavaScript and consider how easy it it to re-use parts of the code. If you have an endpoint that returns a list of things... is it supposed to be paginated over? How easy is that? Is it an infinite list? How easy is that? What would a client want to achieve? Is it possible? When you produce prototype applications in a variety of languages the majority of the small inconsistencies and issues are super obvious. And remember, once the API is out there it's hard to change it and you can't remove things easily... so discovering all of this early helps you get it more right than wrong the first time round. |
|