API output format

Haim

I have created a flow that returns a JSON formatted object via the API functionality.

However, the output when called via Postman includes the End Point name and the object name

How do I stop those two unnecessary items coming out.

A normal REST call would be expected to pass out

Unfortunately I haven't found anything in documentation or videos on this.

Haim

We have found that if the CALLER specifies output type as JSON to RAWJSON the output path variable is not included.

However, I still get the variable name, which is pretty annoying.

ALSO, changing the output type on the DECISIONS side doesn't seem to have any affect, it always returns JSON anyway if not specified by the caller. The Decisions side only seems to mean that VIEW test page adds the specification.

So in reality we can't remove the output path as this would require ALL calls to Decisions specifying the ouput type.

gregory_Decisions

Hello there!

You should be able to remove the "done" output by setting the output type as RawJSON on the View Integration Details page:

This should ensure only the JSON object is returned as output. Regarding the JSON object name, you'd probably have to output the fields individually on the End Step outputs if you wish to avoid the flow name being sent back. 

We hope this helps!

-Gregory

Haim

Yeah, as I said above

"ALSO, changing the output type on the DECISIONS side doesn't seem to have any affect, it always returns JSON anyway if not specified by the caller. The Decisions side only seems to mean that VIEW test page adds the specification."

So all calls to this would need to specify the RawJson parameter. Not really a solution.

The API data type doesn't seem to do anything except affect the "View" testing page.

How is everyone else coping with this? I'd be embarrassed to go to other groups in the company and say I they need to have an end point text and an variable name text included in the return. Anyone else in the community got any comments?

gregory_Decisions

Hello there!

We apologize for the inconvenience this issue if causing for you. Could you open a support ticket for this issue by emailing support@decisions.com? We'd like to investigate your set-up a bit more.

-Gregory

ngreerRymedi

@Haim @gregory_Decisions

Has there been any resolution to this? I have also been frustrated on the inbound call, same issue as above. Most rest endpoints just accept the JSON object........not the input variable name and then the JSON object.

Example:

My JSON object looks like

{

  "ID": "StringValue",

  "Tag": "StringValue",

  "Field": "StringValue"

 }

I have the inbound variable name as "InputTags". When I publish the API from decisions, this is what is generated as input to the service.

{

 "InputTags": {

  "ID": "StringValue",

  "Tag": "StringValue",

  "Field": "StringValue"

 }

}

Is there any way to get around this? I am working with a large company, and we are integrating with their system. I don't have an option to ask them to add "InputTags" to the inbound request.

-Nancy

Haim

Hey @ngreerRymedi

I wrote up a reply (copied below) but then noticed you were talking about INBOUND and not OUTBOUND data. I hadn't noticed that, but you are correct, and this could also be a nuisance for us.

A lot of API's will be without input, or with just an ID of some kind, that's not an issue, but I agree, some kind of PUT where we want to update a larger amount of data in a JSON structure will have the same issue.

We would certainly vote for the ability to have a JSON structure as the root data for Inbound and Outbound interfaces.

Here's my comment about OUTBOUND (which mostly applies to INBOUND).

From the ticket I got:

To avoid the output path tag then the API needs to be set to RawJson. This works from 8.13 onwards (is ignored before this release).

To avoid the Variable tag you need to specify the variables as root output variables. This means you can't use the JSON structure you have created, which is pretty annoying. They weren't interested in supplying any other possibilities.

If you're working with micro-services then probably not a massive hassle and the data you're returning in limited. However, with bigger nested structures it's pretty irritating I would think. Also if you had multiple API's returning the same JSON structure at base level then updates are a drag too.

Our integration team were willing to cope with the break of standard and accept a Variable object name, but then we aren't a massive enterprise and also don't have to expose API's to external partners.

BUT you're talking about input? That shouldn't be an issue

ngreerRymedi

@Haim Thank you so much for the reply! I was hoping to avoid the micro service route but looks like that may be my only option. I do appreciate the info, thank you so much!