Share Embed Donate

Short Description



What are the major differences you can state while using SOAP or REST, in terms of applicability as concern?

Some of the differences that may be observed in applicability of SOAP or REST as the service language/specification :

1. When requirement is to provide a business process as a service, then SOAP may get little more attention than RESTful services. 2. When we are exposing a server side object as many different type of representations for the client, such as JSON, TXT, XML, Audio, Video and many more (HTTP content types) etc. RESTful services can be used/more appropriate than SOAP. 3. In case of contract/interface based service definitions are to be used, then SOAP can be used. 4. In case of exposing a service for any type of devices, be it Desktop/Laptop/Netbook, Tablet, Mobile phones, Kindle etc., and consumer can be a browser (Thin client) or a native application (Thick client). In this circumstances we can opt for RESTful services. 5. In case of many different types of transports are to be used for using a service, then SOAP would be appropriate over RESTful service. 6. For looking for standards-based service declarations and usage, SOAP has many standards to use, such as WS-* standards. Whereas RESTful services would be a specification way of exposing and using any service.

7. Looking at slightly more technical aspects of SOAP, SOAP supports custom objects definitions using XML Schema and marshalling/unmashalling of various datatypes to communicate across diverse platforms.


How can you apply security to RESTful services

Some of the options available to use for securing a RESTful service, for now, are 1. Basic Authentication This type of Authentication will require transport level encryption(SSL), as user credentials are to be sent via wire in plain text.

2. OAuth 1.0a / OAuth 2.0 OAuth 1.0a is using advanced encryption for passing token for authentication purposes. OAuth 2.0 is using SSL for transport level security.

3. Custom/Third-party security protocol Can you write a very simple code showing resource being exposed as RESTful service?

@Path("/book") public class Book {

@GET @Path("{id}")

public Book getBookInfo(@PathParam("id") String bookId) { //return Book Instance by using value bookId. return new Book(); } }

Acessing this Book resource by using an URI as /book/b001

What are the annotations that can be used for specifying content-type that is supported by any RESTful service?

@Produces("text/xml") and @Consumes("text/xml") are the annotations that are used for specifying ways of defining any restrictions that can be defined at method-level for any RESTful service.


For using JAXB supported XML to Custom-object and Custom-object to XML mapping/conversion, along with RESTful service, what are the annotations those can be used along with custom object?

@XmlRootElement, @XmlElement, @XmlAttribute, @XmlAccessorType etc., are the annotations from JAXB can be used along with custom class for defining class, field level fields.

Can you be able to provide certain context-level parameters in web.xml, and receiving parameter value in the resource method?

Answer : One can define context parameter in web.xml file and corresponding value of the parameter in the resource method, by using @Context annotations with instance level variable of ServletContext type. ---------------------------------------------------------------------------------------

What are the headers types from HTTP request, those can be used for mapping same URI but different resource methods?

Answer : One can use Accept, Accept-Language, Accept-Encoding, Content-Type with appropriate values for mapping same URI but different methods. Appropriate method would be called that is receiving corresponding values in form of those headers, in the HTTP REQUEST.

Please keep visiting this page... as more questions will be added here, as and when available. ---------------------------------------------------------------------------------------

Is that any ways to approach so that changes(addition/deletion) in the form-level parameters

would not have impact on the Resource method signature/arguments

Answer : One can explore and its implementations for providing ways to pass form-level POST parameters and corresponding values. This way additions and deletions won't effect method signature to some level.

View more...


Copyright ©2017 KUPDF Inc.