How to describe an API-like request that is browser-to-browser?

Question

I'm building a web application that has a feature which allows visitors to directly access resources using URL patterns, for example:

• www.site.com/client/[clientID]/orders
• www.site.com/client/[clientID]/orders/[orderId]/details

These URLs can be static or dynamic links from other applications/sites. The URLs are secured, but if header of the HTTP request contains the authentication token (e.g. the visitor was logged into the previous site), then the authentication process is invisible to the visitor.

My question is, is it correct to describe this feature as an API? Why or why not? My instinct is no, because the request is received by and returned in the browser. Also, the system as it would not accept a request that did not have that auth token in the header.

My colleagues refer to this as an API, and I'm having trouble explaining why this feature doesn't fit the definition of an API (and what it should be called instead).

Answer 1

Ask a human to do it with pixels and we call it a GUI:

Graphic User Interface.

Ask a human to do it with text and we call it a CLI:

Command Line Interface.

Ask a computer to do it with bytes and we call it an API:

Application Program Interface.

This is likely the mentality of your colleagues. And I'd agree with them with one qualification:

It isn't the API that is doing the authenticating. That's the client that uses the API. A human normally does this by entering a username and pass. The client is doing that part for them by sending the authentication token. We call that automation. The API likely doesn't even know or care how the authentication token was created so long as it's valid. The API's job is to validate the authentication. Not provide it. Whatever provided it is either a human or an automated client.

Answer 2

I would agree with your colleagues.

The browser is (to a lesser or greater degree) an automatism. Among many other things, it's an HTTP client. An HTTP client is totally agnostic to the semantics of the API, hence its security. The client knows nothing about our security protocols, tokens, POST for creating things and DELETE for the opposite, or why did we send a form nor for what is the answer. It knows how to handle HTTP communications (no small thing).

It's the API who drives the security. It does it asking us for credentials somewhere, returning a cookie or header with token(s) for us to resend it later, validating the token sending a request to the issuer or looking for it into the DB, sending a 302 HTTP status to the client to make it moves from the current location to somewhere else, processing the request, invalidating the token due to many connections, etc. The web factor matters. Web takes the PI of the API to another level.