Duda estructura DTO

Por lo que se (que tampoco es mucho) Json no hace lo q quieres y angular tampoco. Eres tu quien le indicas manualmente a que modelo corresponde los datos q devuelve la request

En tu ejemplo, si quieres acceder a la ram deberías asegurarte de que la interfaz incluye el método getRam(), de que las clases sobremesa y portátil lo implementen y acceder a la información a través de dicho método.

Eso o no he entendido una mierda de lo que quieres hacer, que también es lo normal.

PD: estoy desde el.mvl por si algo aparece raro

Interface Foo {
  uid: number,
  first_name: string,
  last_name: string,
  token: string
}

this.httpClient.get<Foo>(
    'http://api.example.com/api/get_user'
).pipe(
    tap((receivedData: Foo) => console.log(receivedData)),
    map((receivedData: Foo) => {
        return new RegularUser(
            receivedData.uid, 
            receivedData.first_name, 
            receivedData.last_name, 
            receivedData.token);
    })
);

He hecho copy paste de algo de inet, pero ahí se ve que al final, eres tu quien indica a que lo mapeas.

#37 Pues realmente ahí depende de lo que se vaya a hacer en el front.

Si necesitas llamar al mismo método implementado de manera distinta en cada clase, tendrás que agregar un atributo que indique el tipo y tenerlo en cuenta para castear manualmente el objeto a la clase acorde.

Si el método es el mismo para ambos, podrías castearlo todos los objetos a una clase padre independientemente del tipo.

Si realmente el tipo cambia la funcionalidad del front (segun el tipo hace unas cosas u otras), lo ideal sería tener 2 endpoints y que cada una devuelva un tipo concreto de objeto (y desde angular, que llame a ambos endpoints)

Es que ya antes de empezar, diría que #1 no se está explicando demasiado bien con respecto a cuál es su situación, y qué busca.

Yo he entendido, y quizá me equivoque, que está trabajando con un tipo de objetos que tiene varios subtipos, y que necesita exponer estos subtipos al consumidor en Angular. El problema de esto, es que sin importar el lenguaje en el que esté hecho el backend, cuando se transfieren esos datos a Angular, el tipado se pierde, así que o bien se expresa en los propios datos enviados (con una propiedad), o bien se parsea directamente en Angular al consumir datos de esa misma API.

El tema es que yo me imagino que tiene una API entry point que consume directamente todos los objetos de esas subclases. Esto tiene sentido si aprovecha polimorfismo, aplicando funciones a supertipos en lugar de a subtipos. Para esto, y con objetivo de conseguir un array de type definitions (que no entity types) del supertipo que usar en Angular, diría que el mejor truco es el siguiente:

const elemsSubClase1 = (await fetch("https://tuweb/api1")).map( elem => new SubClase1(elem));
const elemsSubClase2 = (await fetch("https://tuweb/api2")).map( elem => new SubClase2(elem));
const elemsSubClase3 = (await fetch("https://tuweb/ap3")).map( elem => new SubClase3(elem));
const allElements = elemsSubClase1.concat(elemsSubClase2).concat(elemsSubClase3);

No es el ejemplo más optimizado ni más bonito (sería mejor con Promise.all y proveyendo los entry points y handlers externamente), pero creo que se pilla un poco cuál es la idea. Cabe destacar que yo para situaciones así pondría la superclase como una clase abstracta (algo posible con Typescript, que supongo que lo usarás en tu proyecto Angular), a menos que sea estrictamente necesario instanciar objetos de esa clase. Luego las otras subclases derivarían de ella. Mejor incluso si las propiedades de estas entidades que aluden a comportamientos no necesariamente dependientes del tipo, están segregados en interfaces, pero eso es otro tema ya.

Así, al final de todo este proceso, podrás aplicar el array grande (allElements) a métodos pensados para funcionar para el supertipo, es decir, para todas las subclases.

te voy a acoplar yo la cara al suelo de un meco