Maximo Open Forum

We are integrating an external system with MAS 9 and plan to use REST APIs. 
I'm familiar with the traditional MIF framework (mainly SOAP-based), so I'm trying to understand the correct architectural approach for REST in MAS 9.

1. Can we still use the MIF framework for REST integrations, or is MIF only relevant for SOAP?

2. What exactly is OSLC in the context of MAS 9?

3. When building a REST integration, should we use the standard REST API endpoints or OSLC?

4. What is the recommended approach in MAS 9 for new integrations?

I'd appreciate clarification on the proper architecture and best practice direction for REST integrations in MAS 9.

MIF is the abbreviation for the Maximo Integration Framework. All the integration possibilities (flat file, table, SOAP, REST, etc.) and the components (external systems, enterprise services, publish channels, etc.) fall under this umbrella. 

If you have existing integrations, you may need to make some minor adjustments like switching to API key for authentication instead of basic authentication for SOAP/REST. And you should test for behavioral changes between the versions. But most of your existing integrations should continue to work as written and I wouldn't recommend changing without additional reasons.

OSLC/REST is more confusing than it needs to be. I provided some context here: Post linked document to MAS | Maximo Open Forum but let me try to expand.

There is a legacy REST API (/maxrest/rest) that was developed in the early 7.1/7.5 days that still exists in MAS but shouldn't be utilized in anything in my opinion. This is a scenario I'd actually recommend revisiting to potentially move to the new framework. There are only a handful of features here that aren't possible with the new JSON API like interacting with MBOs without utilizing object structures for example. But these didn't get moved for a reason. Conversely, there are a ton of features in the JSON API that are not possible in the legacy REST framework. 

You'll notice above that I use the JSON API instead of OSLC. I do this to try and help minimize confusion because there are essentially two different APIs on the same context in Maximo. Originally, the /oslc (and now /api for API key authentication) API was for the OSLC standard IBM developed. OSLC has a series of rules around it to make it easier for different products to interact with one another. This was initially added to Maximo to support the Maximo Anywhere product (their previous mobile solution) that was also being developed for the Tririga product. This allowed them to share a lot of the code between the two products even though the systems were very different from one another. You would define OSLC resources and you could generate RDF files (file containing information about the attributes like data types, lengths, scale, labels, etc.) to help the program understand the data model in a generic way. 

OSLC required more setup, resulted in larger JSON responses (due to the prefix naming on all the attributes), and was honestly confusing to explain to a developer. On a single object structure, you could have attributes with a prefix of sp_wm, foaf, dcterms, etc. that you would need to provide in your oslc.select and oslc.where. And outside of IBM, OSLC was never used by other products. 

So, in 7.6.0.3, IBM added what they called the JSON API on top of the OSLC standard. There were some things that they had developed in the OSLC framework (caching for example) that worked really for an API. It didn't make sense to rewrite all of this, so they decided to enable a switch between the OSLC standard and the new JSON API. This required utilizing a query parameter (lean=1) which caused the framework to avoid the OSLC standard naming rules and requirements and used the simplified version. Your oslc.select would be wonum,description,assetnum, etc. which would be easier for developers and administrators to identify. The responses would be smaller which improved download times.

Some documentation links: IBM Maximo REST API Guide – IBM Maximo REST API Guide & Maximo's REST API (aka JSON API, OSLC API) - Asset & Facilities Management

Ever since, the JSON API is the API IBM has been continuing to develop enhancements for. When you see OSLC, REST, JSON API, etc. in relation to Maximo this is typically what people mean. OSLC still exists but only for specific things (like the object structure) whereas there are a ton of new APIs that are not developed to support the OSLC standard. 


Now to the recommended approach, there's reasons all the different integration options exist. But generally, if you're able to, I would recommend the JSON API. Maximo's mobile solution and their new UI framework for desktop are built on this API. There is a ton of functionality here to enable all sorts of unique use cases that wouldn't be possible with SOAP or the legacy REST API and it's constantly being enhanced to add even more capabilities. There is even functionality to help transform your message between Maximo and the other system so you can match their formatting. 

File integrations are sometimes easier to develop with other products but introduce a series of failure points that you need to monitor for. And most importantly, neither system knows if the other system processed the message successfully. APIs (SOAP or REST) return response codes to the sending system so that it knows the message succeeded or failed and why. Conversely, I've seen customers not realize the file consumer cron task in Maximo is stopped and hasn't processed any messages in weeks.