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.
There are 3 different ways you can invoke these types of service operations.
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.
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.
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 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.
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.