4 ms·

I don't understand, what use is a REST API with no state? Who is making remote HTTP calls for calculating e.g. math equations or unit conversions? A stateless R

I don't understand, what use is a REST API with no state? Who is making remote HTTP calls for calculating e.g. math equations or unit conversions? A stateless REST API is completely useless; just do everything locally. For everything else, there will be state to manage, and it's not easy to shove a new version on top of an old version (hence why every API provider agrees to just offer two or more separate versions of the API server rather than having one unified API).

MaxBarraclough 6y ago
I think they meant that the shim can be stateless, as it just defers requests to the new API.
- londons_explore 6y ago
  Exactly.
bspammer 6y ago
A trained model is just a bunch of stateless math but they are often deployed behind an API
saberdancer 6y ago
Address lookups, weather lookup, company lookup, telephone lookup, autocomplete lookups, ... Why wouldn't there be a stateless API?
- corty 6y ago
  Depends on your definition of "stateless". A database is commonly considered state, so database queries are never stateless in some definitions. Answers to stateless queries can be cached indefinitely. Your examples can't. Your definition probably just says that one query shouldn't influence the next one in a session/context/user. The other definition says that any query with the same parameters should yield the same result.
  - xg15 6y ago
    By this logic, there is no such thing as a stateless API because even a trivial "add those numbers" API would rely on the "state" of the server binary or code - which could also change at any time. I think a more useful definition is your second paragraph - i.e. does the server have to keep state specifically for the client that did the last request? This is the case for sessions and for many non-HTTP protocols that need to track state per connection (e.g. TCP tracks connection flags, statistics and sequence numbers, TLS tracks your keys, FTP tracks your current directory, SMTP tracks which data fields were sent, etc etc). It does not apply for simple database searches or even CRUD endpoints because while there is global state (there always is), the server does not care which client in particular made the requests. APIs that have no per-client state can generally be implemented by a shim that internally calls a newer API pretty easily. It's not that easy with APIs that do have per-client state.
vasergen 6y ago
Think here about stateless in this way. Imagine you scaled your API to 2 instances. Stateless here means you don't care which server you hit.
xg15 6y ago
In addition to the DB lookup point, even if the task is only doing calculations that a user could in theory also do locally, there are valid reasons why you'd want to put it behind a network boundary: The calculations may be so complex they require specialized or powerful hardware (e.g. graphics or neural network computations), they may rely on data that you don't want to show to your users - or you may want to keep the details of the calculation itself secret for IP reasons.

MaxBarraclough 6y ago

I think they meant that the shim can be stateless, as it just defers requests to the new API.

londons_explore 6y ago
Exactly.

bspammer 6y ago

A trained model is just a bunch of stateless math but they are often deployed behind an API

saberdancer 6y ago

Address lookups, weather lookup, company lookup, telephone lookup, autocomplete lookups, ... Why wouldn't there be a stateless API?

corty 6y ago
Depends on your definition of "stateless". A database is commonly considered state, so database queries are never stateless in some definitions. Answers to stateless queries can be cached indefinitely. Your examples can't. Your definition probably just says that one query shouldn't influence the next one in a session/context/user. The other definition says that any query with the same parameters should yield the same result.
- xg15 6y ago
  By this logic, there is no such thing as a stateless API because even a trivial "add those numbers" API would rely on the "state" of the server binary or code - which could also change at any time. I think a more useful definition is your second paragraph - i.e. does the server have to keep state specifically for the client that did the last request? This is the case for sessions and for many non-HTTP protocols that need to track state per connection (e.g. TCP tracks connection flags, statistics and sequence numbers, TLS tracks your keys, FTP tracks your current directory, SMTP tracks which data fields were sent, etc etc). It does not apply for simple database searches or even CRUD endpoints because while there is global state (there always is), the server does not care which client in particular made the requests. APIs that have no per-client state can generally be implemented by a shim that internally calls a newer API pretty easily. It's not that easy with APIs that do have per-client state.

vasergen 6y ago

Think here about stateless in this way. Imagine you scaled your API to 2 instances. Stateless here means you don't care which server you hit.

xg15 6y ago

In addition to the DB lookup point, even if the task is only doing calculations that a user could in theory also do locally, there are valid reasons why you'd want to put it behind a network boundary: The calculations may be so complex they require specialized or powerful hardware (e.g. graphics or neural network computations), they may rely on data that you don't want to show to your users - or you may want to keep the details of the calculation itself secret for IP reasons.