Home/ Questions/Q 3302008
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-17T20:48:30+00:00

I have more of a what-would-you-do question than an actual coding question. It relates

  • 0

I have more of a “what-would-you-do” question than an actual coding question.
It relates to a project I am currently working on. In this project,
we are tasked with combining several marketplace APIs into one interface. Each
API has its own unique way of categorizing products. The top-level
parent categories for all the APIs we are looking at are more-or-less
the same with some variations. But, the subcategories are wildly
different.

For example, one API requires long bread-crumb trails
to select a category, such as: Sports > Ball Sports > New England >
Football > Active Teams > Patriots > Memorabilia. While another API has two-level
categorization: Sports > Patriots Memorabilia. In many cases, there are sub-categories
that don’t relate whatsoever to the subcategories of other APIs.

So, the question is – what is the best approach to take when designing
the interface? We are currently wrestling between two possibilities:

1) Design a custom category UI on the client and then build logic into
the server that is able to sort through the needs of the various APIs
based on user-selected choices.

2) Create the UI in such a way that the user has to walk through the
necessary steps for each individual API. Depending on user settings, this means that
he may need to fill out API – specific information 5,6,10, or more
times.

While I am told that option number one is a real programming nightmare (the
example I am given is changing API data fields) I feel strongly that option number two will piss off customers.

Any ideas out there??

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Number One isn’t that bad of a nightmare. Your users’ experience is the number one priority; never forget that. If the user has an easier time navigating a shorter route, then give them that opportunity. Also, I would wrap the API with some abstraction so my code doesn’t know about the API at all and only knows about the abstraction layer. This way I can change APIs and leave most of my code alone, only changing the abstraction layer.

    Use a session to pass data from page to page and a factory to create the page’s state on entry based on the session data; this will strengthen the context between page, state, and user data.

    Keep first level objects (the ones the page directly talks to) in context to the page; this will help when diagnosing problems.

    Most importantly, create a series of tests for your abstraction layer that test every object, function, and input output pair to make sure your application is rock solid.

    • 0