CODEWITHSUNDEEP
restservicestack
kilroyFR
kilroyFR

Reputation: 25

ServiceStack, REST and multiple parameters

I have a question about REST in general.

Imagine I have a WCF webservice that is used to add an operation performed on a bank card. The problem is that there are about 30 different parameters to pass on the WS.

On WCF that's pretty easy to do, calling a RPC with all those parameters.

The problem is that I wanted to switch this WCF WS to a REST API with ServiceStack.

The problem I encountered is that if i try to create the operation using REST and passing parameters through 'querystring', I have a string that is AWFUL for reading and VERY VERY LONG (?amount=1234&operationID=12& etc.).

I know this way of doing is not good as it's not resource oriented, but does that i mean i should split the creation of that item into SEVERAL steps (I mean, first create using POST then adding new infos/fields using several post ?).

In this situation I can't see clearly the gain with REST.

Upvotes: 1

Views: 910

Answers (2)

Kevin Junghans
Kevin Junghans

Reputation: 17540

If you are passing these parameters in a query string I assume you are performing an HTTP GET. In a REST API GET's are generally reserved for getting data back and the only parameters you pass in are to filter your results. If you are performing an operation that changes the state of the system you want to perform a POST or PUT and pass the data in the body of the message as either XML or JSON, not in the query string.

The gain with REST is if you are opening this API up to other as it makes it much more portable to heterogeneous systems and there are some performance benefits. It also opens your API up to being used by clients such as web browsers. But if this API is just for internal use with .NET application that is not run in a browser then you may want to stick with WCF. REST is not the answer for every problem.

Upvotes: 1

Aurélien Bénel
Aurélien Bénel

Reputation: 3842

I am not sure to understand your question... REST doesn't mean "no payload". On the contrary, REST means "representational state transfer", so the body of HTTP requests (aka "representational state") is essential.

For a lot of reasons, in the case of a bank, resources are usually bank operations. CouchDB's guide has a very nice scenario about that.

In other words, your "parameters" would be the attributes of the resource representation (in JSON, XML or what you want) you would GET, POST, PUT or DELETE.

Upvotes: 0

Related Questions