I would suggest utilizing Maximo end points. Maximo is designed to handle HTTP connections from an integration perspective, and it handles an abstracts a lot of the code portion while still giving you almost complete control of the connection. You don't need any additional libraries to be downloaded, and you know it will continue to be supported by IBM. It also gives you a good place to store information about your integration while allowing the script to override anything that is necessary. For example, we integrate with a monitoring system in two ways (retrieve monitoring IDs and another to schedule downtime for maintenance events). We're able to store the pieces that are constant in the endpoint, and override what we need to change for that particular integration (such as using a POST request instead of a GET request).
Federated MBOs that Diego mentioned is also a good system for certain integrations, especially if you're just retrieving information, but doesn't make sense in all cases. There's overhead in setting up a MBO that isn't necessary if you're just trying to process it in an automation script for example. And if you need to be able to update these MBOs, you have to build your own logic to push updates anyways.I had a response on the old forums that I'm struggling to find. This was written pretty quick, so if there are questions on it please let me know.The first thing you have to do is declare your endpoint in the End Points application. Create a new end point and ensure the handler is HTTP. Provide what you can in the end point configuration (such as URL, HTTP METHOD, headers, etc.). Anything that you need to set in the script, ensure that the Allow Override checkbox is checked. I've shown an example below that we use. If your service uses basic authentication, you can provide the username/password fields and it will handle that, otherwise leave those two fields null.
Regarding: "Create a new end point and ensure the handler is HTTP."
Have you found that HTTPS does not work? If so, do you know why?
All of our end points are HTTPS. There are a couple of areas that could impact people. The most common is WebSphere doesn't trust certificates unless added to the trust store.
Beyond that, certificates greater than 2048 bits weren't allowed without replacing some policy files until relatively recent. I know with WebSphere 9 and Java 1.8 it is no longer required, not sure which earlier versions it was fixed in.The final thing is WebSphere 8.5.5 by default doesn't support TLS 1.2 for outbound connections which is now becoming a requirement. This was changed in WebSphere 9 but is an easy change to make in 8.5.5.Those are the most common things we've seen.