Optimal way to expose Tridion content to external systems?

Question

We are currently using SDL 2013SP1 with Spring MVC at the front end and want to expose the HTML fragments to other external systems.

1. Is creating REST API over ODATA a good option where external systems can simply simply use the URI?
2. Will this effort go waste if we plan to go with DXA 2.0, are there any OOB REST API available with DXA?
3. Are fragments module of DXA actually a REST call & can external systems simply plug and play and can retrieve the content from Tridion like below: /{lang}/{comp_id}/

update

I am referring to https://community.sdl.com/product-groups/sdl-tridion-dx/tridion-sites/tridion-developer/b/weblog/posts/salesforce-community-cloud-integration and am under the impression that DXA provides the public Content API & HTML fragment is one of the modules in DXA 2.0.

Answer 1

Whether creating a REST API over OData is a good option for you, nobody can answer but you I would say. Simply using a REST service is commonly accepted as one of the easier ways for external systems to connect, but if that should use OData or something else is something you can come up yourself with best, it might also be depending on the external systems.

If you plan to build a REST service now yourself to expose Tridion content, and later want to move to DXA 2.0, then it again depends on whether your effort has gone to waste. DXA 2.0 does have a Model Service, but that is not considered part of the public API, so you are not encouraged to start using that from an external application. The reasoning behind this is that there are plans for a new Public Content API service in SDL Tridion Sites 9, and that would then most likely replace the DXA 2.0 Model Service.

update

On your last question (and the update you provided on that), DXA does come with with some standard fragments for header and footers, but it does not contain a fragment module out of the box (as you can see in the documentation). Niclas (the author of the article you mention), created some examples in a custom DXA module (for which you can download the source from his GitHub repository: https://github.com/NiclasCedermalm/dxa-fragment), that DXA add-on module can be used to publish your content as standalone HTML fragments indeed.

Note at the time of writing his module is developed using DXA 1.7, it might need some updating to work on DXA 2.0.

Answer 2

Update:

I see @Bart updated his answer. Here's my update in case someone is looking for info about that specific integration.

The Salesforce CMS Connect basic integration expect HTML from whatever CMS it connects to.

The DXA modules by @NiclasCedermalm, you're considering include:

• https://community.sdl.com/product-groups/sdl-tridion-dx/tridion-sites/tridion-developer/b/weblog/posts/salesforce-community-cloud-integration
• https://community.sdl.com/product-groups/sdl-tridion-dx/tridion-sites/tridion-developer/b/weblog/posts/quick-start-to-use-salesforce-community-cloud-with-vanilla-dxa

And the actual code:

https://github.com/NiclasCedermalm/dxa-fragment

The straightforward way to integrate with Salesforce CMS Connect is to create pages and expose the markup to that system.

---

Original answer:

+1 to @Bart's answer. I'd add "people" to the point on systems (which consist of people, process, and technology). The use case could be teams in the same company or external organizations and the needs can vary. You could also consider your own team's skills and preferences since you'll own the service.

It's hard to tell if you'd prefer OData or something else. :-)

Confirm the Use Case

For questions #1 and #3, the problem with something like /{lang}/{comp_id}/ is this ignores your content model and use case for integrations.

For example, if you wanted to share articles with other systems, I'd expect titles or dates to be exposed rather than IDs, especially if I didn't know Tridion.

As another example, for the Salesforce integration work, we assumed Connectors would use the Salesforce ID to identify a re-visiting contact (sales lead). But a preferred use case was to leverage the Content Delivery session ID to recognize a returning visitor. So what's really needed is something like field=some_value rather than assume a system's ID is necessarily relevant in different contexts.

I'd prefer this "semantic" approach as well to help test across DTAP where titles may be the same, but IDs may differ.

Options

If you're looking for what you might consider, I've heard of a few customers or partners that have started or explored Java, .NET Core, or whatever for a back-end that exposes RESTful API alongside a Swagger (OpenAPI) definition.*

I don't see a problem with OData, per se, and apparently, you could do an OData service with an OpenAPI definition.

Unified Delivery is exploring GraphQL, which seems like a good fit for lighter-weight queries and entities that really have some meaning behind them (semantic).

*In terms of API specifications, I hear luke-warm expectations for *generated* clients, but this seems to go back to code generation in general. Most seem to appreciate/expect the specs for developer-friendly documentation and we're trying to use OpenAPI for that for all our new services.

Fragments?

I'm not familiar with a fragments DXA module. You can get a DXA website back in json format, if that's what you're thinking about.

I think creating something for your use case wouldn't be a waste if it solves your technical and business needs and especially if you need to evolve your content API independent of the underlying product(s). Just be sure to leverage Content Delivery for features like link resolving, the ADF, etc.

For more generic queries, sure, we'll introduce more features in the product and DXA so it'll depend on when you want such functionality and timing on your upgrade.