The fundamental explanation is:
No client session state on the server.
By stateless it means that the server does not store any state about the client session on the server side.
The client session is stored on the client. The server is stateless means that every server can service any client at any time, there is no session affinity or sticky sessions. The relevant session information is stored on the client and passed to the server as needed.
That does not preclude other services that the web server talks to from maintaining state about business objects such as shopping carts, just not about the client's current application/session state.
The client's application state should never be stored on the server, but passed around from the client to every place that needs it.
That is where the ST in REST comes from, State Transfer. You transfer the state around instead of having the server store it. This is the only way to scale to millions of concurrent users. If for no other reason than because millions of sessions is millions of sessions.
The load of session management is amortized across all the clients, the clients store their session state and the servers can service many orders of magnitude or more clients in a stateless fashion.
Even for a service that you think will only need in the 10's of thousands of concurrent users, you still should make your service stateless. Tens of thousands is still tens of thousands and there will be time and space cost associated with it.
Stateless is how the HTTP protocol and the web in general was designed to operate and is an overall simpler implementation and you have a single code path instead of a bunch of server side logic to maintain a bunch of session state.
There are some very basic implementation principles:
These are principles not implementations, how you meet these principles may vary.
In summary, the five key principles are:
- Give every “thing” an ID
- Link things together
- Use standard methods
- Resources with multiple representations
- Communicate statelessly
There is nothing about authentication or authorization in the REST dissertation.
Because there is nothing different from authenticating a request that is RESTful from one that is not. Authentication is irrelevant to the RESTful discussion.
Explaining how to create a stateless application for your particular requirements, is too-broad for StackOverflow.
Implementing Authentication and Authorization as it pertains to REST is even more so too-broad and various approaches to implementations are explained in great detail on the internet in general.
Comments asking for help/info on this will/should just be flagged as
No Longer Needed.
That REST call is correct. I am using TeamCity 7.1. Could it be that you simply haven't had any failures since the last successful build? Try inverting the conditions:
/guestAuth/app/rest/builds/?locator=status:success,sinceBuild:(status:failure)
This will return a list of successful builds since the last failure (the opposite). If you get results with this query, then your query should return no results. In otherwords, of these two queries:
/guestAuth/app/rest/builds/?locator=status:failure,sinceBuild:(status:success)
/guestAuth/app/rest/builds/?locator=status:success,sinceBuild:(status:failure)
At any given time, given that there are completed builds, one should ALWAYS return zero builds and the other should ALWAYS return one or more builds.
Best Answer
As per the TeamCity REST API documentation from JetBrains, the builds can be located either of the following ways:
OR
This is must to have the buildType is being suffixed by a
<buildTypeLocator>as per the current REST API if you are trying to query something under the buildType and<buildTypeLocator> can be id:<btXXX_internal_buildConfiguration_id> or name:<Build_Configuration_name>(Quote from documentation). So it is must that you need to specify build id or build name.But, the ideal way as you expected will be something like:
Probably, you can raise this up in TeamCity Support I suppose.