API Taxonomy Query

sidd-harth
Participant V

Hi guys, can someone explain me about on how to approach for developing an API taxonomy across the ecosystem using Apigee. In doing this, the taxonomy must support HATEOS APIs.

I got brief understanding about taxonomy from Google, but I'm still confused on how to apply this to APIs.

1 6 784
6 REPLIES 6

@Barahalikar Siddharth , Frankly, first time i heard "API taxonomy" from you, can you please add more context to your query / what exactly is the use case / what you are trying to achieve ?

@Anil Sagar Even I did not heard about this, till one of our client wanted to know our approach towards it.

After googling for sometime I got to know that it is not API Product specific.It is related to data.

Below link has an example,

https://doc.lucidworks.com/fusion/2.4/REST_API_Reference/Taxonomy-API.html

I thought there would be some notes in Apigee regarding it.

@Barahalikar Siddharth

Based on the links, it seems like it's a design principle. In Apigee, You can just implement same by creating API Proxies with the structure explained in the link you have shared.

Regarding HATEOS, Again make sure output adheres to HATEOS APIs standard so that links are provided in response. I see it as a rest design issue & you can implement same in Apigee.

@Prashanth Subrahmanyam , @seshi , @sudharshan@apigee.com Have you come across anything like above requirement while designing retail APIs ?

@Anil Sagar How does Taxonomy work in Drupal? Is it anywhere related to API Taxonomy?

@Barahalikar Siddharth , It has similarities in concepts. Drupal taxonomy is used to categorized content in CMS. API Taxonomy is applying taxonomy concept to API design & entities.

@Barahalikar Siddharth I am unable to quite understand what exactly you are looking for.


When you say API Taxonomy it sounds like you want something by which you are able to organize and classify APIs.

When you say Taxonomy API, then it sounds like an API that is used to create and maintain taxonomies.

On the face of it, it sounds like two different things. The first one being a best practice or guidelines, where as the second one is a specification or a specific API.

Could you kindly find more details from your client about what they are looking for and elaborate; maybe I can help better.

HATEOAS itself is a pattern that is complementary to REST. It (loosely) means that related REST APIs should be self discoverable.

What does this mean?

Think web pages. You don't land on a page and then automagically know the link to another page on the website. You don't key the URL of the new page that you want to go to. When you land on a page you are presented with related links to other pages and you can navigate by just clicking on the link.

Similarly, REST API responses should reference to other API endpoints so that the client can easily jump from one call to the next related call without having to know all about the API and having to construct it by some rules.

Now what is the taxonomy you are looking for here, I am still unclear.