In the context of a debate, the question arises: What security measures should be considered when the client possesses knowledge of all the endpoint names? The scenario involves the client being aware of the specific locations or addresses where services are exposed on the server side.
Not really any different then someone knowing URL's of a web site?
As long as those API's don't use database PK id's, or if in that case the API's limit data to a given database PK based on the user's logon.
So, no, it should not be a issue.
I don't as a general rule expose database PK id's to the client side web page (JavaScript), nor do I allow as such for a API calls.
However, in the cases that database PK id's are allowed to be passed, then a restriction (server side) based on the users logon has to be enforced, else I could pass say a credit card number that belongs to someone else and say get their balance.
However, as noted, the same basic restrictions for a web page in general that allows or uses or exposes say a database PK id to the client side web page has to be further tested and filtered.
So, even a simple textbox on a page that prompts for say a invoice number? Well, that invoice balance or invoice number query still has to restrict data based on the users logon.
Quite much the same basic concepts are thus applied to a web API, and like any simple data input used for data query on a simple data entry page?
That user input has to be SQL injection safe, and often that data set returned also has to be filtered based on the user's logon.
So be this a simple web page, or a simple API call, the rules are quite much the same.
For example, on a simple web page, if a user selects a value from a table (or gridview, or whatever), then I don't expose the database PK's in that case, and I'll pass JUST the row index selection to server side code. However, with a web API, then the datakeys list for that table is unlikely to have been persisted or available. Thus, once again, be this a simple text box that prompts for some "id", or a API call? Quite much the same rules apply.
So, as a result, there should be no more, or less security risk from a basic web page that accepts input, or that of a API call.
And thus it follows that knowledge of a particular web page, or a particular web API should not matter.
On the other hand, if those API can say execute raw database functions, then you have a huge security issue. However, that security issue is not the result of some API, or some web page, but that of design ensuing that such user supplied input is valid, and also not dangerous, nor can it allow one to get or grab data that does not belong to the current user in question.