In a given B2B scenario, where an enterprise exchanges order, invoice, ASN messages with it’s customer, where does REST fits? What are the parameters a customer should have and what are the parameters the enterprise should have to say it’s REST capable? Only ESB or the gateway accepting HTTP methods isn’t enough to say it’s REST capable.
REST is an architectural style. It is not a technology.
You’re absolutely right that the use of HTTP doesn’t mean that something is RESTful. The presence or absense of a particular set of parameters doesn’t make something RESTful either. There is much more to it than that.
Fielding’s paper defines a number of characteristics/constraints of the REST architectural style. An architecture would need to adhere to each of those to be considered RESTful.
Generally speaking, the vast majority of interfaces that claim they are RESTful are not. Fielding is known for making this point and has written about his frustration with people misusing the term.
All that said, it is possible to define a component that adheres to the REST constraints for the “B2B” scenario you describe. Just keep in mind that it is not as trivial as structuring a URI in a particular way or simply using HTTP (indeed, use of HTTP is not a REST requirement). You may find this post by Fielding to be helpful.
Thank you Reamon. The article helped me a lot.
Thank you Raemon for sharing such an informative post with us. Appreciate it.