I understand services should have no state and no business logic.
- How can you implement a service like AuthentificationService considering these rules?
- All the methods in a service should be static?
Let's look at the various parts of your question.
Your statement (and assumption) is only partly correct.
This is mostly true, rounded up to almost always true. The problem is that coding state into a service gets to be a real pain. Keeping track of the state; client requests; timeouts; disconnects; slow responses; load balancing; distributed service provisioning; session hijacking; etc... all adds up to a lot of overhead. So it's just easier to not have state in the service. The problems listed mostly go away, and the features are easier to implement.
Not true. In fact, a service is essentially a manifestation of business logic. A service must provide a function. That function represents something of value to the business, and is generally a piece of the organization's business logic.
I think this depends upon what you mean by
But if you mean "unchanging" then the answer is yes. A service should provide a deterministic response to a properly formatted response. How it generates that response may change, but the form and nature of the response should be static. A service is an API, and once released to the wild then it should not change. If a change is required then consider applying versions to your services.
See above for the misunderstandings in your base assumptions.
Many frameworks provide this service out of the box so long as you plug the framework into your authentication provider. The general approach is that credentials are based to the
You could make the semantic argument that the token represents a "state" for the client session. But the token or "state" tracking is handled by the client and there are very simplistic rules on the service side in order to validate and handle that "state." Many / all of the woes associated with stateful services are still avoided.