Skip to main content
corrected spelling, corrected grammar, improved formatting
Source Link

My team needneeds to design an API which sends objects to a queue in the cloud and retrieveretrieves objects from it. The data is inserted tointo the queue inas byte[].

We have 2 ideas until now which I would love to hear your notsnotes/ideas about them:

First version:

  • public void push(String object)
  • public String retrieve()

Notes: To support this API, any consumer must implement a logic to convert his objects to Strings and visevice versa.

Advantages:

  1. Easy to implement.
  2. Easy to maintain.

Disadvantages:

  1. The consumer of our API must design a solution which is not related to his logic for converting his objects to StringsStrings.
  2. The consumer of our API must call a method which convertconverts his objects by him selfhimself even thoughtthough it is not related to his logic.

Second version:

  • public void <T> push(T object)
  • public T <T> retrieve(Class<T> type)

Advantages:

  1. Easy to implement. (In Java, we can use ObjectMapper)
  2. Easy to use this API.
  3. The consumer of our API does not need to manually convert menually his objects to anything else.

Disadvantages:

  1. The types of the consumer of our API must support Json converts - Recursivlyrecursively, Aa class with obejctsobject properties, all propertiesproperty types must support Json converts.
  2. If the consumer does not read cerfully the documentation If the consumer does not read the documentation carefully, something won't work or there will be a silientsilent bug.

General notes:

  1. The API needneeds to be supported for at listleast 4 years.

My team need to design API which sends objects to a queue in the cloud and retrieve objects from it. The data is inserted to the queue in byte[].

We have 2 ideas until now which I would love to hear your nots/ideas about them:

First version:

  • public void push(String object)
  • public String retrieve()

Notes: To support this API, any consumer must implement a logic to convert his objects to Strings and vise versa.

Advantages:

  1. Easy to implement
  2. Easy to maintain.

Disadvantages:

  1. The consumer of our API must design a solution which is not related to his logic for converting his objects to Strings.
  2. The consumer of our API must call a method which convert his objects by him self even thought it is not related to his logic.

Second version:

  • public void <T> push(T object)
  • public T <T> retrieve(Class<T> type)

Advantages:

  1. Easy to implement. (In Java, we can use ObjectMapper)
  2. Easy to use this API.
  3. The consumer of our API does not need to convert menually his objects to anything else.

Disadvantages:

  1. The types of the consumer of our API must support Json converts - Recursivly, A class with obejcts properties, all properties types must support Json converts.
  2. If the consumer does not read cerfully the documentation, something won't work or there will be a silient bug.

General notes:

  1. The API need to be supported for at list 4 years.

My team needs to design an API which sends objects to a queue in the cloud and retrieves objects from it. The data is inserted into the queue as byte[].

We have 2 ideas until now which I would love to hear your notes/ideas about them:

First version:

  • public void push(String object)
  • public String retrieve()

Notes: To support this API, any consumer must implement a logic to convert his objects to Strings and vice versa.

Advantages:

  1. Easy to implement.
  2. Easy to maintain.

Disadvantages:

  1. The consumer of our API must design a solution which is not related to his logic for converting his objects to Strings.
  2. The consumer of our API must call a method which converts his objects by himself even though it is not related to his logic.

Second version:

  • public void <T> push(T object)
  • public T <T> retrieve(Class<T> type)

Advantages:

  1. Easy to implement. (In Java, we can use ObjectMapper)
  2. Easy to use this API.
  3. The consumer of our API does not need to manually convert his objects to anything else.

Disadvantages:

  1. The types of the consumer of our API must support Json converts - recursively, a class with object properties, all property types must support Json converts.
  2. If the consumer does not read the documentation carefully, something won't work or there will be a silent bug.

General notes:

  1. The API needs to be supported for at least 4 years.
Source Link
Stav Alfi
  • 297
  • 3
  • 10

Design public API - String or generic type?

My team need to design API which sends objects to a queue in the cloud and retrieve objects from it. The data is inserted to the queue in byte[].

We have 2 ideas until now which I would love to hear your nots/ideas about them:

First version:

  • public void push(String object)
  • public String retrieve()

Notes: To support this API, any consumer must implement a logic to convert his objects to Strings and vise versa.

Advantages:

  1. Easy to implement
  2. Easy to maintain.

Disadvantages:

  1. The consumer of our API must design a solution which is not related to his logic for converting his objects to Strings.
  2. The consumer of our API must call a method which convert his objects by him self even thought it is not related to his logic.

Second version:

  • public void <T> push(T object)
  • public T <T> retrieve(Class<T> type)

Advantages:

  1. Easy to implement. (In Java, we can use ObjectMapper)
  2. Easy to use this API.
  3. The consumer of our API does not need to convert menually his objects to anything else.

Disadvantages:

  1. The types of the consumer of our API must support Json converts - Recursivly, A class with obejcts properties, all properties types must support Json converts.
  2. If the consumer does not read cerfully the documentation, something won't work or there will be a silient bug.

General notes:

  1. The API need to be supported for at list 4 years.