Recently I have started using a new(to me) paradigm for web services. I use the controller to accept JSON strings sent over POST, process it and return JSON strings. GET, PUT, DELETE and other methods throw HTTP 405.This pattern is proving to be very efficient from the point of view of asynchronous web frameworks (vert.x and play to be particular), as well as from development effort point of view.What I am confused about is that this neither seems to be SOAP nor REST. I don't think it is even JSON-RPC, since I am using my own headers like:Request:{  'requestId':<generated req Id>,  'token':<previously authenticated token>,  'action':<controller defined action>,  'parameters':[    <array of parameters>  ]}Response:{  'result':'success/fail',  'payload':{     <payload>   }}EDIT: There is only one endpoint URL, something like https://my.domain.com/apiCan anyone give any ideas about what this paradigm can be classified as?
Can a webservice that uses JSON over POST be classified as RESTful?
web services;rest;json;soap
There are really two definitions of REST:Representational State Transfer (REST) as a principle for service design (not necessarily web service!), which suggests a uniform client-server interface where the server does not store the client context, e.g. client has visited this page last.  As a general principle, RESTful services shuold request a specific resource -- e.g. an article, or an order object -- as well as an action to perform on that resource -- get, tag, paint yellow, or whatever is necessary, so long as the same action for different types of resources gets the same name. So long as you follow these principles, your web service can be RESTful even if it does not use HTTP.  I don't see the specific resource being requested in your protocol , but then again, it may be defined by the URL.  EDIT: As you are not specifying the resource independently of the action, your service is not RESTful by this definition.REST as a specific request format that uses HTTP as carrier protocol and HTTP request types like GET, POST, or DELETE to specify what type of action needs to be carried out.  Your service is obviously not RESTful by this definition.The most general description of your protocol would be likely a service for remote procedure calls (RPC) over JSON, but which is not JSON-RPC.  To be clear, there is nothing wrong with not being RESTful or being RESTful.  Whatever suits your needs.