-2

I have created a web-service which involves accepting certain parameters in URL, validation the and returning XML response to client using JAXB xml library. Recently I came across JAX-WS framework which uses SOAP over HTTP to transfer request/response to/from client. Am I losing something by using simple servlet + connection pooling and serving XML response over HTTP ? Client will be hitting the URL created via some systems which are not known yet.

Is there any advantage to use REST or SOAP protocol, when simple HTTP + XML or JSON can solve the problem.

dpanshu
  • 453
  • 3
  • 14

1 Answers1

1

Sounds like you do not have any constraints over what you serve which leaves you with loads of options. There are quite a few angles to approach this question from, I just list some of the most obvious practical considerations below and leave out any architectural discussion.

SOAP is generally (but not always) used for enterprise integration - but it has a lot of shortcomings - not least in its verbosity. My advice would be not to use SOAP unless you really have no choice in the matter.

XML or JSON ? would your clients prefer to consume JSON or XML? If you are just publishing the service and not consuming it then I would go with JSON since it is becoming a very popular message format now for web services.

If you are the only one consuming the response then you need to think about what your client technology/framework would likely prefer to parse and how big the message payload is likely to be. If it is rich (loads of nested objects and attributes) then an XML schema might suit, but if the messages are very large then consider that the JSON footprint is likely to be smaller than the XML one.

You are not missing anything in your approach. Go for the simplest option - which depends on what framework/libraries you are using and the skill-set of your developer(s). If a servlet appears to be the most straightforward to you, go with that. If your data is already in XML then that seems like the way to go, but if not, I would consider publishing JSON format first. If you're not sure how to do that, first have a look at Jackson.

Update:

If you are still not sure which way to go then just serve JSON. Also, the format of the messages you consume/publish should not dictate how you implement your application design - I mean, the question to use a servlet or not does not really factor into what message format to use, unless you intend to use a framework which ties you to a particular approach eg. Play Framework will very easily allow you to serve JSON from a Controller (not Servlet) so if you were using this framework - for example - you would not want to use a servlet and you would use JSON since that is the easiest way to go because of the out-of-the box support the framework already provides.

jacks
  • 4,614
  • 24
  • 34
  • So can we say there is no advantage of using SOAP, it should be only used when the client has the limitation of using SOAP or some other specific protocol. – dpanshu Jul 30 '15 at 05:20
  • 1
    Well that is actually a big debate that we don't want to get into. SOAP still has its uses and it is a widely adopted standard - mainly in enterprise-level middleware integration. What I would say is that unless you are constrained to using SOAP steer clear of it since the implementation will likely be more complicated than just marshalling XML or JSON. – jacks Jul 30 '15 at 10:25