The other day I received an interview offer from a recruiter, who forwarded me the usual list of requirements.  The fifth line of the required skills irked me:

- Knowledge of SOA (REST, JSON, etc.)

Let's start with the fundamentals. JSON is a protocol of data exchange. You can do data exchange in just about anything: XML, YAML, HTML, JSON, BSON, IDL, even some tragic home-grown mess that only your client and server understand. But that's all it is: a way of marshaling data at one end of an exchange between two independent programs such that at the other end it will be parsed, understood, and acted on appropriately. These are all designed to be transmitted over some mediated electronic network such as the Internet, but carrier pigeon would work.

SOA and REST are architectural decisions about how to organize your client/server software project. More than that, they are opposite decisions: choosing one means you are choosing not to use the other.  SOA ("Service Oriented Architecture") concentrates on the service delivered, on how data is handled, whereas REST is concerned about the data being handled.  One is verb-oriented, the other is noun-oriented.

If you think this is an academic distinction, you're right.  But it's an important one that people screw up all the time.  Consider this analogy: going to the movies.  In a noun-oriented word, you trade money for a ticket; you trade the ticket for access; you use the access to find a seat; you use the seat to watch a movie.  That what REST does: it trades coarse documents back and forth between the client and the server describing the various records that need to be kept to accomplish a goal, which ultimately results in the client and the server agreeing on what each needs.  In a verb-oriented world, you're not writing software dealing with money, tickets, access, seats and movies: instead, you end up writing software about the kid selling tickets, the kid _taking _tickets, the kid who ushers you to your seat, and the _projection _of the movie.  That's what SOA does: it describes the services with which you're provided, not the actual products you intend on handling.

I can fairly be described as a REST partisan, but then my world is full of concrete items: gene sets, stories, to-do items, gardens, potlucks, cards, poems, games.  When I program, I care about what the client and the server exchange.   In every case, the software must validate and ensure the integrity of the exchange,  but in the case of REST the medium of exchange describes what is being exchanged, not how to exchange it, and for me that makes a big difference.  When you say you want "SOA using REST," you're telling me you don't really understand either.