New Video: Consume a REST API in 10 minutes with OutSystems

Modern applications rarely live in a vacuum, and almost always require access to external services, whether written by your developers, or exposed by third parties. And a majority of those services today rely on REST to expose and consume their functionality.

But consuming REST services can sometimes be challenging or fiddly. OutSystems provides tools to simplify and accelerate the consumption of REST APIs, and in this Quick Hits episode, Developer Advocate Cristiana Umbelino shows you just how quickly you can consume the Stripe payments REST API using OutSystems. 

Thanks for sharing this information!

When exposing the result of an integrated service, the video shows using the structures from the integration. Would it not be safer to expose a different/separate structure ? That way you decouple the consumers from the integrated service, so that when the service changes, your consumers are not impacted directly?

Another advantage would be that you can limit the fields you expose, or give them other (and better) names than the fields in the service.

Hi Tim,

While it depends on the context, yes - you are correct

Just for clarity, the goal for the Decoded Quick Hits video series is to show what you can do with OutSystems in quick, short videos. If possible, in a manner that sets up first timers to the use case (in this case consuming REST APIs) to build a solid foundation. I opted to not include the separate structures, the handling of exceptions/errors or even the OnBefore/OnAfterRequest since this would make the video longer and more complex.

We are aiming for more in-depth educational content in the Tech Talk In-Depth series, OutSystems User Groups or Training Tech Talks.

Hope this makes sense for you.

Nonetheless, thank you so much for your feedback! We will be more attentive to this kind of detail and include it if possible. Even if it's just commenting while I'm doing it "the quick way".

Thank you!

Cristiana, don't get me wrong ;) I think this is great content and I agree keeping these videos short for the reasons you mentioned.

I just wanted to give a bit of extra info and open the discussion a bit as well, since this is the forums after all. But perhaps it was not the best place.

Oh not at all! I probably misunderstood your comment as feedback to the content on the video, sorry about that.

So getting a bit more deep into your question then :)

I do believe there's a time in a project where you can get away with using the exact same structures from the REST API (which would be the Integration Service (_IS) module) and mostly if they are simple and fit the use case the team is developing.

However, as things get more complex or if you are building for the future it makes perfect sense to build what I would call the "Data Dictionary" for your domain. For example in Stripe's case, you would have another structure called Payments that would normalize and simplify the Response from the API.

Basically I'm just repeating what is written in the Integration Patterns for Core Services Abstraction article.

Does that align with your experience in the Integrations universe?

Yes, that's completely in line with my experience. There are times you just want/need to make speed, and other cases where you need to think more ahead and build for the future.

As always, it is finding the right balance between those 2. 

Thanks for your feedback, and for the video as well. This is great help for someone learning the platform. (and for those who need a quick refresh)

Good share!! Thanks


Thanks for sharing this information!

That's really nice content!!!

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.