Hi all, thanks for reading. This question is about the use of Restful services when being used either by the front end (Angular) or API (someone tried to write their own code to use your services).
Notice: I am at the moment just learning; NOT building something. Therefore its not a question to provide code snippets or anything but just debate the Question parts below. I will then continue learning based on what you might recommend.
What I already know: So I was reading about the best practices in terms of security (for any site which requires a state), you should always use a cookie and make use of the SessionID so that the Server knows its the same session of that same person etc...
Front End Example: So in my front end (say using Angular, KO or whatever), I am using a browser which can store Cookies and I can make full use of the browser to keep some kind of state. This is by far clear enough from what I am reading
Question: So if these services had to be used by another developer instead of by Angular, (and I believe I am really confused in this part) doesn't that force the developer to have a kind of browser implemented in his/her code?
Question2 Or perhaps say the developer using these services is going to use Java with Spring... which Spring module would you need to learn and know (apart from Core and Conext and MVC) in order to be able to connect to these services?
Example: I was thinking that for login, one would have something like and once login is complete and the browser has a cookie with the sessionId and perhaps some other UID for more safety etc... the user can make something like to check out the user info. Thus the rest would send a json with the required details.
Question on Example How would the developer using the /login and /user_details services go about that? I mean in code not using Angular
The problem possibly lies in your first "What I already know".
RESTful services are supposed to be stateless, which means you don't need to worry about sessions anyway.
Now, there is a possible exception if you are using a cookie simply for authentication, but there are other ways, using the headers of the request.
A more workable approach is to have the login return a token and send that token as a parameter in subsequent requests. This is not pretty, since you have to explictly include the parameter in every call and on top of that, the token ID's part of the visible URL, so it can be exploited from client history and snooped over the network if you are foolish enough not to use SSL.
Not that cookies are much better, but you do have to examine actual content to see them and the higher-level Java HTTP clients handle managing the cookie automatically.
As Dave said, statefui and ReST don't really go together, though. For the reasons previously mentioned and quite a few more.
Sources may include data from the Fakebook Research Foundation with support from Gargle University
Here. Have a potato. I grew it in my armpit. And from my other armpit, this tiny ad: