Should I REST or SOAP
Moderator: General Moderators
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Should I REST or SOAP
I am familiar with SOAP yet have never used it (to my knowledge) and had no clue about REST until just now after searching Google.
I need to transfer sensitive data between two remote machines as web services...
It sounds as though REST is for accessing "resources" not "services" so any REST implementation that includes complexities like, authentication is over kill.
With this insight, it would seem logical one would then want to consider using SOAP.
Which should I use? What are the true differences between them? I recall seeing a SOAP class in Zend, is it complicated, could I use it to base my own classes on? Quickly and effectively?
I need to transfer sensitive data between two remote machines as web services...
It sounds as though REST is for accessing "resources" not "services" so any REST implementation that includes complexities like, authentication is over kill.
With this insight, it would seem logical one would then want to consider using SOAP.
Which should I use? What are the true differences between them? I recall seeing a SOAP class in Zend, is it complicated, could I use it to base my own classes on? Quickly and effectively?
- Kieran Huggins
- DevNet Master
- Posts: 3635
- Joined: Wed Dec 06, 2006 4:14 pm
- Location: Toronto, Canada
- Contact:
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
REST and SOAP are not really that comparable though they seem to get lumped together as methods of communication. REST is an architectural style and SOAP is a protocol. You may want to compare SOAP and RPC, and then in turn compare RPC and REST to get a sense of the continuum of communication styles. They all exist because they serve different requirements.
(#10850)
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Most of the articles I've read really stress that SOAP is the protocol and REST is the architectural style, which I understand, as there are few specifics to using REST to GETPOST HTTP requests and the format is whatever is dictated by the returned XML or the format of the GET requests.
However, what is unclear, is how I might make REST secure for accessing/updating sensitive records when using REST? It seems some feel REST is not to be used for secure transactions?
I could build a simple API over top REST so that it mimics something of SOAP with authentication, etc...is that most REST apps work when they implement security?
Have the REST server return a session id to the client after authenticating and use that session ID there after on each request to the server?
How would you all recommend implementing a layer of authentication to prevent outside access to sensitive data when using REST?
Believe, REST is the way I *want* to go but I'm unclear whether it's capable or best practice to use under the security requirement???
Any opinions.
However, what is unclear, is how I might make REST secure for accessing/updating sensitive records when using REST? It seems some feel REST is not to be used for secure transactions?
I could build a simple API over top REST so that it mimics something of SOAP with authentication, etc...is that most REST apps work when they implement security?
Have the REST server return a session id to the client after authenticating and use that session ID there after on each request to the server?
How would you all recommend implementing a layer of authentication to prevent outside access to sensitive data when using REST?
Believe, REST is the way I *want* to go but I'm unclear whether it's capable or best practice to use under the security requirement???
Any opinions.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Doesn't sound like REST would be tecnically suited for anything of sensitive nature.wikipedia wrote:HTTP separates the notions of a web server and a web browser. This allows the implementation of each to vary from the other based on the client/server principle. When used RESTfully, HTTP is stateless. Each message contains all the information necessary to understand the request when combined with state at the resource. As a result, neither the client nor the server needs to remember any communication-state between messages. Any state retained by the server must be modeled as a resource.
- Kieran Huggins
- DevNet Master
- Posts: 3635
- Joined: Wed Dec 06, 2006 4:14 pm
- Location: Toronto, Canada
- Contact:
All Lettuce & Tomato Wheel Drive?astions wrote:REST ALTWD
http://www.berenddeboer.net/rest/authentication.html could be useful
REST really does make your life easier, it's "the right way" to have model access.
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
HTTP Authentication ring a bell? 
REST can be secured - I think the main problem that's noted is that some REST authentication methods may leave a service open to phishing and man-in-the-middle vulnerabilities. This is largely a design problem - not a fundamental one for REST. It's relatively easy to impose API keys, shared/negotiated secret keys, etc, to defeat MITM or weak authentication. A classic solution is to sign all messages between server and client with a shared secret key to assert that messages are valid (not MITM junk).
If you're exposing a public service to authenticated members, OAuth is certainly worth a good look. It's very new and presently implemented by Twitter and Magnolia.
REST can be secured - I think the main problem that's noted is that some REST authentication methods may leave a service open to phishing and man-in-the-middle vulnerabilities. This is largely a design problem - not a fundamental one for REST. It's relatively easy to impose API keys, shared/negotiated secret keys, etc, to defeat MITM or weak authentication. A classic solution is to sign all messages between server and client with a shared secret key to assert that messages are valid (not MITM junk).
If you're exposing a public service to authenticated members, OAuth is certainly worth a good look. It's very new and presently implemented by Twitter and Magnolia.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
SOAP, RPC or some kind of REST communication are all secure -- over HTTPS.Jenk wrote:That still begs the same question.. how is SOAP more secure than REST when both use the same HTTP service. SOAP is a defined XML format, still uses strings over HTTP. REST is a dynamic string over HTTP.
As I said above, they are different styles of communication that meet different requirements. It's a lot like choosing between TCP and UDP, different for different requirements.
Better one is not...
(#10850)
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Well the fact that REST advocates seem to stress the importance of "stateless" behavior makes it less secure. Sure you could integrate authentication but without sessions or something, you would have to pass the user/pass in everytime you make a request, so unless you used HTTPS, wouldn't that be insecure?That still begs the same question.. how is SOAP more secure than REST when both use the same HTTP service. SOAP is a defined XML format, still uses strings over HTTP. REST is a dynamic string over HTTP.
As for the use of an API key...I have considered possibly using something like a private key implementation to encrypt the messages...
Maurgim, thanks for that OAuth...I'll certainly check it out.
Cheers
- Kieran Huggins
- DevNet Master
- Posts: 3635
- Joined: Wed Dec 06, 2006 4:14 pm
- Location: Toronto, Canada
- Contact: