Not quite. As the L in URL says, it is the locator or address of the state. The S in REST implies the same, indicating states as the content, not path to it.

▲

Scarblac 4 days ago | parent | next [-]

But from the viewpoint of a web app where you navigate between different (versions of) pages, the state of that app can be the address of the currently displayed page.

	▲	zkmon 4 days ago \| parent [-]
		It's the state of your browser, not the app. App could be serving different pages to different clients at the same time.

▲

layer8 4 days ago | parent | prev [-]

State is just your location in state space.

▲

zkmon 4 days ago | parent [-]

An address book is not "state space". The country, land and things are the state.

▲

layer8 4 days ago | parent [-]

Not every location represents a state, but every state can be considered a location.

If you want to argue against the use of URLs to represent state, I would concentrate on the “R” (resource) aspect.

▲

zkmon 4 days ago | parent [-]

I think you are talking about client's navigational state. The original title of this post was "app state ...". Still it is not clear about state of what.

Navigational state need not be confused with app state. Also talking about "state" as in "state machine" etc used to sound pretty academic with obscure meaning of the word "state". When someone says "state machine" they are basically saying "I'm a PhD and you are not". There are simpler and more crisp ways to convey things rather than via obscurity.

	▲	layer8 3 days ago \| parent [-]
		My point was a linguistic-conceptual one, that a location fully describing a state is not a contradiction in terms, and hence it’s not necessarily a misuse of the “URL” concept regarding the “locator” aspect. Navigational versus application state is irrelevant to that argument.