add support for swagger object type

[LeePui]

Description

Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.

Fixes # (issue)

Type of Change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update, included: Dify Document
• Improvement, including but not limited to code refactoring, performance optimization, and UI/UX improvement
• Dependency upgrade

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• TODO

Suggested Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• I ran dev/reformat(backend) and cd web && npx lint-staged(frontend) to appease the lint gods
• optional I have made corresponding changes to the documentation
• optional I have added tests that prove my fix is effective or that my feature works
• optional New and existing unit tests pass locally with my changes

[LeePui]

Hi , i think supporting simple object types would be very useful for Dify.

Dify likely serves a substantial number of commercial clients, predominantly enterprise-level users. One common application for these users is in AI-driven sales, where the AI interacts with users, gathers their requirements through dialogue, and then recommends products based on those needs.

A typical workflow on Dify involves the AI extracting user tags from these interactions and then forwarding these tags to a recommendation service via an intermediary tool, which then suggests relevant products to the users.

Given the non-enumerable nature of tags generated from natural language, it’s impractical to specify exact tag names in interface parameters. Consequently, the interface accepts parameters of type Map<String, Object>, where the key is the tag name and the value is the user's selection. My testing with both GPT-3.5 and GPT-4 confirms that they can seamlessly handle such parameter types.

Therefore, I believe that support for 'object' types would significantly benefit enterprise users in implementing these types of workflows. In fact, upon reviewing the codebase, I noticed that Dify’s frontend already supports 'object' types; however, the backend lacked proper object handling. To address this, I have added an object type check in the backend within the code I submitted, which, based on my testing, functions effectively.

[LeePui]

Hi , i think supporting simple object types would be very useful for Dify.

Dify likely serves a substantial number of commercial clients, predominantly enterprise-level users. One common application for these users is in AI-driven sales, where the AI interacts with users, gathers their requirements through dialogue, and then recommends products based on those needs.

A typical workflow on Dify involves the AI extracting user tags from these interactions and then forwarding these tags to a recommendation service via an intermediary tool, which then suggests relevant products to the users.

Given the non-enumerable nature of tags generated from natural language, it’s impractical to specify exact tag names in interface parameters. Consequently, the interface accepts parameters of type Map<String, Object>, where the key is the tag name and the value is the user's selection. My testing with both GPT-3.5 and GPT-4 confirms that they can seamlessly handle such parameter types.

Therefore, I believe that support for 'object' types would significantly benefit enterprise users in implementing these types of workflows. In fact, upon reviewing the codebase, I noticed that Dify’s frontend already supports 'object' types; however, the backend lacked proper object handling. To address this, I have added an object type check in the backend within the code I submitted, which, based on my testing, functions effectively.

@Yeuoly Hi, Yeuoly, I've made some additions to the use case and the logic that's currently missing in Dify. Could you take a look at it?

[Yeuoly]

Thanks for your contribution, and I consider it as an important feature that implements lots of amazing and useful tools.

However, supporting OBJECT type is complex work, for example, a child object could be nested, arrays could be declared also, we should define a more flexible struct to implement this, and more changes should be done.

I do understand that what we need is a simple struct and it meets most needs, but I think we can do it further.

current changes make sense in simple context, let's make it better! would you mind implement it? or I can just accept this PR and make it later.

[LeePui]

Thanks for your contribution, and I consider it as an important feature that implements lots of amazing and useful tools.

However, supporting OBJECT type is complex work, for example, a child object could be nested, arrays could be declared also, we should define a more flexible struct to implement this, and more changes should be done.

I do understand that what we need is a simple struct and it meets most needs, but I think we can do it further.

current changes make sense in simple context, let's make it better! would you mind implement it? or I can just accept this PR and make it later.

@Yeuoly ,Hi, thank you for your reply. I think I can try to refine the handling of the 'object' type. I will complete this implementation in the next few days. I think we can merge this simple version first, and then I'll continue to refine it.

[Yeuoly]

LGTM

[Yeuoly]

Thx for contributions :)