Languages are like tools. PHP is good for certain tasks, Java is good for others. Node.js is good in some contexts, and Ruby is good for others. Those are all languages that you can just on a server. I like to use Java because, well, that's what I'm used to. That's what I learned to program with, and it's what I use at my day job. So it makes the most sense for me to stick with what I know. I chose to write a Java-based server tutorial because if you're coming from the other tutorials on the site (starting with Processing and working your way up through Java), then sticking with Java makes sense.
westSchool/people/Adam instead of
people/Adam is fine. That's still a URL, so you're still using a URL to represent your objects. A violation would be if, for example, you required the user to first submit a
POST request to
setPerson with data that contained
Adam and then submit a
GET request to
getPerson to get Adam's data. That means your requests are no longer standalone, which is a violation of REST principles.
Maybe a more likely scenario is handling logins: it's pretty easy to use sessions to manage user logins, but using sessions is a violation of REST principles. So you have a decision: do you try to stick with a "pure" REST solution and require login information be passed with ever request, or do you go with a "REST lite" solution and keep using sessions?
There is no right answer to that question. Like I said in the tutorial, there are no REST police that will come kick your door down if you don't obey every "rule" of REST. It's completely up to you how strict you want to be.