This question is in the context of web based applications. A web serverexposing an HTTP api for clients (e.g. running in a browser but notnecessarily). Usually the web server would be connected to somekind ofdatastorage.My concern is the API exposed by the HTTP server, and how to design it.I find that, often, a big part of api exposed to the client is just aCRUD interface to the datastorage. For example, the api almost alwayscontains things like:- get_all_users()- get_this_user(id)- create_new_user(name, email, phone, password)- update_user(id, name?, email?, phone?, password?)- delete_user(id)This is not all the API does, but it something that is common to a lotof APIs I've worked with. Depending on what the client needs, I often end up with more and morethings in the API such as these:- get_user_by_email(email)- get_all_users_along_with_number_of_lincenses_for_each()- delete_all_these_users_at_once(array [])- get_users_whose_profile_is(profile_name)- get_names_of_users_who_are_admin_profiles()- .... etcIn other words, the client often needs to do joins, filter, and sort thedata in all kinds of ways.Which has led me to overly bloated APIs (just like the one above)supporting all kinds of options for filtering, sorting, and joining withdata from other tables.The resulting API is too complex for both the client to use and learnand for the server to maintain and test.(IMO the Zabbix HTTP api suffers from this syndrom).Questions:Do you have similar experience?Do you have some pointers as to how to strike a good balance betweenAPI completeness and complexity.PS. I'm aware of REST, but I don't find it resolves the problem, the apiprovided is still very basic, and doesn't solve theget_users_along_with_number_of_licenses() or theget_names_of_users_which_are_admin() api calls.;
Designing CRUD part of an HTTP API
web development;web applications;rest;api design;web api