This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Compare to WS Rest is having advantages in terms of simplicity in use. But still most of the development happening in WS. Is their any significant advantage or disadvantage between these 2 technologies ?
Ulf is right, both can be determined as being webservices. Normally, though, when you talk about webservices in teh enterprise world, people immediately assume your talking about SOAP/HTTP webservices. Webservices defined by a large number of specifications.
I don't really know whether most development is really done in the traditional WS-* space. In large organisation SOA is equivalent with SOAP/HTTP, and I agree, they still do a lot of SOAP/XML/XSD/WSDL type development. When you look outside the enterprise environment, however, you see people moving away from the often complex traditional webservice approach. Most 'services' on the internet are more often than not developed using a light-weight REST/JSON approach.
Both approaches have their advantages and disadvantages of course.
What about authentication? I have a clear picture for SOAP, but I still do not get it for Restful web services. Does anyone know any improvements for the last two years regarding secure communication in Restful? I would appreciate, since I may need it soon.
Joined: Mar 22, 2005
AFAIK, there is nothing in the works like WS-Security for REST. Unless you want to roll your own, that means Basic or Digest Authentication.
Joined: Sep 04, 2012
True, there is no standards based authentication/encryption/security framework available for REST, such as WS-Security for SOAP services. A lot of people say that since we got https that's enough for the encryption and integrity part and that with HTTP authentication we could handle the rest. You can probably fulfill most scenarios with these two technologies, but often https just isn't feasible or you want a different authentication method than just HTTP authentication.
It all really depends on your scenario. For integrity and authentication, for instance, you can add a simple HMAC to your message, calculated based on a shared key. If it's an API you're creating for third parties you can give out API keys that are sent with the request and tied to a specific host name. So for the authentication part there are a couple 'roll-your-own' solutions that are easy to implement. Encryption isn't something that is often done on the message level in JSON over REST, the only real option is using HTTPS. You could, if you really would like message based encryption use XML as the payload and use the standards for XML encryption.