Understanding SOAP versus REST versus HTTP web services in PeopleSoft

This section pertains to synchronous web services which we will go into great detail in the later sections of this book.

Synchronous Service Operations are characterized as a request/response interaction style. The client sends in some request to PeopleSoft and it waits while PeopleSoft gets or updates data and generates a response and sends it back.

Sync Interaction Model

There are 3 different ways you can invoke these types of service operations.

  • REST
  • HTTP Post
  • SOAP

REST

REST uses the HTTP protocol extensively. It attempts make use of many of the HTTP protocal features including HTTP verbs (PUT, POST, DELETE, GET) and HTTP Status codes. REST was introduced in the Integration Broker with PeopleTools 8.52.

With REST:

  • Clients submit requests to the RESTListeningConnector
  • The name of the service operation being called is included as part of the URL path.
  • Parameters could be mixed into the URL query string, URL path and HTTP Body depending on the API design.
  • No Integration Broker nodes are used
  • The security mechanism is generally using “basic auth” tied to a PSOPRDEFN.OPRID and password.
  • Unit testing in Postman is very easy.
  • The JSON support prior to 8.56 was extremely limited. Therefore, XML data format is the most supported encoding scheme.

Read more in the REST Introduction section

HTTP Post

Until REST was introduced in PeopleTools 8.52, the HTTP Post method via HttpListeningConnector was the best and most simple way to call service operations for external clients. This is more of an RPC style web service.

With HTTP Post:

  • Clients submit requests to the HttpListeningConnector
  • Normally XML data is submitted in the request and XML is returned. There is some support for other content types but XML is generally the default.
  • The security mechanism is generally handled through HTTP headers and node settings.
  • They are fairly easy to test and work with in an HTTP testing tool.

SOAP

SOAP is old, SOAP is bloated, SOAP does not make you clean (but soap does). Unless you absolutely have to use SOAP for some reason, I recommend using one of the other styles of messaging. This book will spend very little time discussing SOAP.

With SOAP:

  • clients submit requests to the PeopleSoftServiceListeningConnector
  • Messages must have a SOAP wrapper
    • This make testing not as simple as the other methods.
  • Error responses are wrapped in a SOAP fault message
  • Security is handled differently that the other methods and is arguably more complex.

Random Reasons NOT to use SOAP:

  • It relies on the client to import SOAP libraries to that lead to more code dependencies.
  • There can be subtle differences between PeopleSoft’s SOAP implementation and your client’s libraries leading to bugs and inconsistencies.
  • Unit testing SOAP services with a tester tool like Postman is hard because the message structure is complex.
  • WSDLs and XSD are a pain to work with and PeopleTools has basic support and lots of rough edges.
    • Additionally, I don’t really think WSDL’s and XSD provide that much functionality. They may give a 10,000 foot picture of the messages involved and maybe the URLs. However, they don’t get involved in the gritty detail at the field level and how different fields interact with one another. For example, if you give value “x” for field “A”, then the options for field “B” become limited further. That is not covered in those schema and where I find that 99% of the client code has to deal with.
  • The documentation from Oracle is completely lacking. There are no start to finish examples, there are conflicting documentation articles, etc.

Opinion’s From Around the Web


Author Info
Chris Malek

Chris Malek is a PeopleTools® Technical Consultant with two decades of experience working on PeopleSoft enterprise software projects. He is available for consulting engagements.

About Chris Work with Chris