There is no technical difference between the terms – you may as well have asked about “Color” vs. “Colorful”.
REST is an architectural style with well defined constraints. That is, if your system does not conform to them, then it is not a RESTful system.
Here are the constraints:
• Statelessness – session-state is maintained by the client and the server never stores any client context between requests.
• Uniform Interface – ultimately, clients should be able to enter, understand, and use a RESTful system knowing nothing more than the entry point.
• Client-Server Architecture – This shouldn’t really need much explanation: decoupling a UI from the application and storage allows for simpler interactions and reusability of component application segments.
• Cacheability – Can be implemented on the client or server side and must be declared in every case.
• Layered System – APIs may be deployed to one server although the processing, storage, authentication, and other concerns may happen elsewhere.
• OPTIONAL: code on demand – when returning static representations pf resources in JSON or XML won’t do, just go ahead and return executable code – you are allowed.
Here are a few other useful points:
• REST is often compared to SOAP but this is like comparing apples to oranges. SOAP is a protocol – REST is not.
• REST is protocol independent. We often use it with HTTP but we could just as easily use a different protocol for a different purpose.
• A good understanding of hypermedia and HATEOAS is crucial to getting the Uniform Interface constraint satisfied effectively.
• No one is going to grade you on how well your system conforms to REST and occasional deviations are encountered in even the most sophisticated systems. Just know that the closer you get to pure REST, the longer you can expect your application to remain relevant to your organization.
Hope this helps!