As PeopleSoft customers move to REST, I've noticed an interesting trend: choosing code over metadata. Most of the examples I've seen online are labeled Easy or Simple. Some of the examples use fully supported documented approaches, whereas others use undocumented internal testing methods. Here are some of my favorites:
Based on those examples, REST PeopleCode really is easy! But what does that say about the metadata approach? Is it hard? Is it complex? To answer that, let's review the metadata definitions necessary to craft a REST request:
- UR Document (if the target has parameterized URLs)
- URI Message (if the target has parameterized URLs)
- Request Document (if POST, PUT, or PATCH)
- Request Message (if POST, PUT, or PATCH)
- Response Document
- Response Message
- Service
- Service Operation
- Service Operation Security
And when you are done with the metadata configuration, you must still write code to invoke the REST request. Interestingly, invoking a REST metadata-based request requires roughly the same amount of PeopleCode as a "simple" or "easy" PeopleCode request.
So what does all that Metadata buy us? In other words, why choose metadata over pure code?
- Logging: We can set the log level in the routing.
- Security: OAuth and Basic Auth options can be set at the routing level.
- Parsing: Document-based messages will parse JSON, XML, and Rowsets for us.
- Maintenance: We can update/change URLs online rather than through PeopleCode (although a URL definition is a very simple way to maintain URLs across instances).
What if you don't require these features? Perhaps choosing the simple PeopleCode approach is better? Let us know your thoughts in the comments!
We teach PeopleTools REST and Integration regularly through our three-day Integration Tools Update course. Check out our website to see what we are offering next!