REST API Metadata

andresanche
Giga Guru

I am doing integrations using the REST API and am wondering if I've found all the metadata available for each API.

So far, I've been using:

- CSVs and sample Json responses in the documentation

- metadata using the sys_dictionary table

 

Specifically, I'm looking for metadata that outlines how different plugins change each API. For example after installing the Customer Service Install Base Management (com.snc.install_base) plugin, new fields became available in the Case API. 

I know for custom fields to look at sys_dictionary where fields are prefixed with u_. Is the best way to find these "new" fields added by plugins to compare the fields I have based on the csv/sample JSON in the documentation to whats actually being returned via sys_dictionary?

Thank you,

1 ACCEPTED SOLUTION

Enrique8956
Giga Contributor

You're definitely on the right track with using sys_dictionary to compare fields and identify what's available post-plugin installs. It's like detective work, but with more lines of code and fewer trench coats.

The approach of checking sys_dictionary for new fields added by plugins (especially those without the u_ prefix) is solid. It gives you a peek into the additional metadata that those plugins sneak into your APIs. But instead of going through CSVs and JSON samples from the docs every time, you can streamline the process a bit.

Here’s the plan:

Baseline the API Fields: Before adding any plugins, grab a list of fields for each API you're using by querying sys_dictionary. This gives you a "before" picture.

Post-Plugin Check: Once you've installed the plugin, run the same query on sys_dictionary again and look for the new additions. This is your "after" picture. Focus on fields that don’t have the u_ prefix since those are typically added by the plugins or the platform itself.

Spot the Differences: You can automate a comparison between your “before” and “after” lists to identify what changed. Boom—now you’ve got a quick way to track which fields those plugins added.

If you're feeling fancy, throw a little automation around this so you're not manually running these queries every time. You could script something to pull the pre- and post-plugin sys_dictionary data and highlight differences. Think of it like a "find the differences" puzzle, but for API nerds like us.

Just don’t get too lost in the fields—someone might accuse you of going down a rabbit hole. Or worse, becoming too obsessed with sys_dictionary tables. 😅

View solution in original post

1 REPLY 1

Enrique8956
Giga Contributor

You're definitely on the right track with using sys_dictionary to compare fields and identify what's available post-plugin installs. It's like detective work, but with more lines of code and fewer trench coats.

The approach of checking sys_dictionary for new fields added by plugins (especially those without the u_ prefix) is solid. It gives you a peek into the additional metadata that those plugins sneak into your APIs. But instead of going through CSVs and JSON samples from the docs every time, you can streamline the process a bit.

Here’s the plan:

Baseline the API Fields: Before adding any plugins, grab a list of fields for each API you're using by querying sys_dictionary. This gives you a "before" picture.

Post-Plugin Check: Once you've installed the plugin, run the same query on sys_dictionary again and look for the new additions. This is your "after" picture. Focus on fields that don’t have the u_ prefix since those are typically added by the plugins or the platform itself.

Spot the Differences: You can automate a comparison between your “before” and “after” lists to identify what changed. Boom—now you’ve got a quick way to track which fields those plugins added.

If you're feeling fancy, throw a little automation around this so you're not manually running these queries every time. You could script something to pull the pre- and post-plugin sys_dictionary data and highlight differences. Think of it like a "find the differences" puzzle, but for API nerds like us.

Just don’t get too lost in the fields—someone might accuse you of going down a rabbit hole. Or worse, becoming too obsessed with sys_dictionary tables. 😅