Reputation: 82547
I am working with another team that is providing me a web service to call.
The web service has a few methods that I can call and it gives response values.
I recently found out that they are coding it as a "RESTful" service. I am not very experienced in RESTful services, but to my (very limited) understanding, traditional method calling is not what REST is about (though it can be done).
Is REST the wrong approach if all you are doing is creating custom web methods to call?
NOTE: I think this is the other teams first real experience with web services. I am worried that they have been beguiled by the REST buzz and are not using the best protocol for what they are building.
Upvotes: 1
Views: 68
Reputation: 24590
What you are describing sounds to me as RPC over HTTP and that can't be called REST as you are basically at level zero of the Richardson Maturity Model.
REST is an architecture style which allows a lot of freedom in the implementation. But you still have to respect the REST constraints, mainly the HATEOAS.
Is REST the wrong approach if all you are doing is creating custom web methods to call?
In most cases SOAP is used for this scenario, but people are somehow afraid of SOAP (maybe because of it's bad reputation for being called "Simple" when it wasn't) and prefer to go for something simpler which is basically a HTTP RPC API that they believe is actually REST, when it isn't.
In conclusion, you can keep your web service as it is - if it's safe and meets your needs - but you can't call it REST. It's RPC.
Upvotes: 1