django - tutorial - drf yasg

¿Es una mala práctica combinar REST y RPC?

Question

Soy bastante nuevo en los servicios web REST y muy acostumbrado a RPC . Conozco las ventajas de REST al leer varias publicaciones como esta .

Estoy desarrollando el servidor en django usando django-rest-framework.

Aunque tiene esta pregunta (o preguntas):

Tengo este modelo:

class Poll(models.Model):
questionString = models.CharField(max_length=500, blank=True)
timeToAnswer = models.IntegerField(default=30)
startDate = models.DateTimeField(null=True, db_column=''startDate'', blank=True)
token = models.CharField(max_length=20, blank=True, unique=True)
class PollAggregator(models.Model):
name = models.CharField(max_length=135)
description = models.CharField(max_length=500, blank=True)
votersToken = models.CharField(max_length=20, null=True, blank=True)
class PollPollAggregatorRel(models.Model):
pollAggregator = models.ForeignKey(PollAggregator, null=True, db_column=''pollAggregatorId'', blank=True)
poll = models.ForeignKey(Poll, null=True, db_column=''pollId'', blank=True)

Entonces puedo tener una sola encuesta o puedo tener un grupo de encuestas agregadas en un agregador de sondeos (es decir, sala).

Así que creé las llamadas restantes: pollList, pollDetail, pollAggregatorList, pollAggregatorDetail. Pero tengo problemas para diseñar para PollPollAgregatorRel. Por supuesto, puedo tener PollPollAgregatorRelList y PollPollAgregatorRelDetail y hacer la publicación normal, obtener, actualizar, eliminar. Entonces, si quiero establecer una nueva relación entre una encuesta y un agregador de encuestas en estilo REST, lo hago:

• Comprueba si PollPollAgregator (list) existe con el ID de encuesta con get y filtrado por pollId
• Si es así, actualizo este elemento para tener mi nueva identificación pollAggregator
• Si no, creo un nuevo PollPollAgregator con una publicación

Mi primera pregunta es si hay alguna manera más fácil y simple de hacer esto.

Si utilizo un servicio web similar a RPC, hago algo como:

• Relacione la encuesta con pollAggregator y use un get_or_create para PollPollAggregatorRel. Así que actualizo o creo un nuevo objeto PollPollAggregatorRel.

Entonces, al usar RPC similar, el cliente usa solo una llamada versus REST que necesita llamar 2 veces. En este caso, parece ser mucho más simple de usar RPC tanto para el servidor como para el cliente.

La segunda pregunta es: ¿es una mala práctica usar tanto REST como RPC en la misma API?

Answer 1

P1: Creo que sería razonable proporcionar una operación POST estilo REST que devuelva un agregador existente o cree uno nuevo según sea necesario. Lo cual, lógicamente, no es muy diferente a su servicio "RPC".

Creo que parte de su dificultad puede ser que esté diseñando sus "llamadas" de REST (sugerencia: no son "llamadas", son "recursos") demasiado cerca del modelo subyacente. Es un error que cometí en el pasado.

REST! ​​= CRUD.

Un beneficio clave de REST es que permite que la interfaz se separe del modelo, por lo que el servidor puede cambiar su implementación sin afectar a los clientes. Otro beneficio clave es que minimiza la cantidad de información que el cliente necesita saber de antemano para realizar alguna operación. Por ejemplo, un cliente REST debería ser capaz de descubrir todos los URI de recursos que necesita utilizar al interactuar con el "recurso frontal" (por analogía con "página de inicio") del servicio.

Entonces, consideraría un enfoque en el que los siguientes recursos cubren lo que usted describe arriba:

1. una página de inicio de servicio, cuya representación contiene enlaces (o plantillas de enlace) a los otros recursos (o devuelve enlaces a través de encabezados de enlace HTTP)

2. un recurso de "recopilación de sondeos" que proporciona la creación y el acceso a encuestas individuales (por ejemplo, GET devuelve la lista de todas las encuestas, POST crea una nueva)

3. encuestas individuales, cuyos URI se descubren mediante interacciones con la "colección de encuestas". OBTENER, PONER, ELIMINAR hacer lo que cabría esperar. No estoy seguro si necesitaría POST para estos.

4. un recurso de "administrador de agregación" que asocia encuestas con agregaciones (¿puede una encuesta pertenecer a más de una agregación? - su descripción no sugiere). ¿Una POST a este recurso que contiene un URI de POLL podría localizar o crear una agregación (o agregaciones?) O crear una nueva. GET puede devolver una lista de agregaciones existentes.

5. recursos de agregación individuales cuyos URI se descubren mediante interacciones con el recurso del administrador de agregación.

En su descripción, PollPollAggregatorRel es parte de su implementación (actual), no es algo que expone como tal a través de la API REST. Esto le da flexibilidad para cambiar su implementación interna sin afectar la forma en que los clientes usan la API. Ese es el punto de REST.

No estoy seguro si consideraría esto como "más fácil y simple", pero ese no es el sentido de REST. REST ha sido descrito por Roy Fielding como "ingeniería de software en una escala de décadas", y el objetivo es crear una interfaz que permita una evolución relativamente independiente de las implementaciones de clientes y servidores, lo cual es crucial para una aplicación que opera a escala web. Hay un precio a pagar por esto, que es que el cliente tiene que interactuar con el servidor para descubrir la información que necesita para progresar en una interacción.

P2: No consideraría sensato mezclar REST y RPC en la misma API . (Podría tener mucho sentido exponer REST a clientes externos y usar RPC internamente, o ofrecer API separadas).

Mi razón de ser es que si tiene una API REST en su mayoría, agregar un elemento RPC crea potencialmente un acoplamiento estrecho entre el cliente y el servidor que, en primer lugar, niega el uso de REST.