Introducing a small but powerful PeopleSoft bolt-on that makes web services very easy. If you have a SQL statement, you can turn that into a web service in PeopleSoft in a few minutes.Read More & Purchase
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.
Read more in the REST Introduction section
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:
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.
Random Reasons NOT to use SOAP:
If you are developing a bespoke solution for your specific organization and you are on the latest tools release then REST might be the way to go.
If you are a software vendor developing a PeopleSoft web service that needs to be deployed to unknown clients then HTTP might be a safer bet. I do a lot of work here. I have different clients that have software products that need to integrate with PeopleSoft. I have developed standard PeopleSoft web services that are deployed to various client sites that integrate with these products. In this situation you cannot target the most up to date PeopleSoft release. What often happens in this situation is that a client might be on an older PeopleSoft release and you need to have the code developed in a manner that will work for all possible clients. In this situation, I use HTTP and XML because it will be portable across a very wide range of clients. The software application talking to these web services will just know how to talk to those web services. The number of People in this situation is likely small.
To be honest I don’t see a huge difference between REST and HTTP due to the way PeopleSoft is structured. I will cover this more in later sections.