• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

SOAP and REST Services

 
Ranch Hand
Posts: 441
2
Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Generally, it is mentioned that SOAP services have a pre-defined structure in the form of WSDL and REST are flexible not having any kind of contract. But, as per my understanding, if we have to use JSON or some other format, i believe the producer and consumer must have some contract so that they can convert the objects and get the appropriate values. Suppose, if we add some field in JSON at producer, then how the consumer will extract it if we don't modify the consumer's code.
 
Rancher
Posts: 115
8
Mac Mac OS X Safari
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The purpose of SOAP(and WSDL) are to be a strongly typed messaging contract that can go over multiple protocols(SMTP, TCP, as well as HTTP). WSDLs were built to describe how the message and endpoints wanted to be structured. This allowed tools to code-generate proxy classes. SOAP was built to let backend services talk to each other.  Since HTTP wasn't the only target protocol, SOAP 1.0 essentially ignored transport security. However, as firewalls got tougher, all traffic just went over HTTP because port 80(Non-SSL) was almost always opened. So they ended up needing to specify some extra security in later versions. While it was built to be a messaging protocol, it ended up being a way to make Remote Procedure Calls. The code generation tools usually transparently wrapped the parameter list into an Xml serialized argument object, and the endpoint was the function name. If you have tools to do this work for you, you can ignore almost all of SOAP's quirks. It had far too much structure, and later security, to be of much use talking browser to server.

REST is designed to just use HTML, with its own security/header/location/error mechanisms, instead of the SOAP envelope and transport. The lack of messaging structure for REST meant that the contract was something between the caller and the receiver, not the protocol intermediaries. This made it really easy to handle in Javascript on the browser. Better serialization architectures on the server usually meant it was fairly easy to parse things into JSON, XML, CSV, or whatever format the client asked for using MIME types. Your code might not even know the difference.

Nothing about REST absolves you of responsibility for having a stable(or backwards compatible) contract with the consumer. If you want to have some documentation of the structure of your REST document, you just need some other mechanism to define or validate. If your document is XML, create an XSD. If you are using JSON, you can use JSON Schema for the data. Or you can use OpenAPI (Swagger) definition. as a more comprehensive REST endpoint/document schema(Essentially a WSDL for REST). It is entirely possible to create a contract so rigid that you replicate all the worst features of SOAP.

 
Bill Crim
Rancher
Posts: 115
8
Mac Mac OS X Safari
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
something I missed...

Most things that use JSON as their serialization format, allow you to ignore things you don't understand. Or they allow for partial objects. Especially since Javascript objects can have extra values added to them at any time. I know lots of people who don't use Serializer at all, and instead use something like JSONObjects from the org.JSON package to just access the data as a series of arrays and hashtables. So if you add a new field, I would not worry too much about it breaking the caller.


The other thing to keep in mind. Don't use internal data structures as your source of document data. Create a set of Data Transfer Objects that go with your endpoints. Then use an object-to-object mapping tool to help you fill them out. This helps when you want to create different versions of the REST service.  "test.com/api/v1/Data" vs "test.com/api/v2/Data", then just make sure Version 1 and Version 2 both work. If you have a "Data_v1" and  "Data_v2" objects, you can then use a mapper to create them both from your internal "DataBusinessObject". That way you have 2 simplified paths for data transfer objects, but only 1 path for business logic.

Here is a short article that talks about versioning REST APIs, and a description of all the many ways you can do it. REST API Versioning. There isn't one right way to do it.
 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic