¿Cómo traducir la consulta SQL en solicitudes API REST?

Digamos que tengo una descripción legible por máquina (como en WADL , Swagger o RAML ) de una API REST que proporciona interfaz a una base de datos.

Mis usuarios envían consultas sobre la base de datos subyacente en forma de SQL o lenguaje de consulta similar. Sin embargo, no puedo acceder a la base de datos directamente, solo a través de la API REST.

¿Qué enfoque elegiría para construir (preferiblemente semiautomáticamente a partir de la descripción) un sistema que traduzca dichas consultas SQL en una secuencia de solicitudes a la API REST dada?

¿Cómo representaría usted ese problema? ¿Existen algoritmos, marcos teóricos o herramientas que puedan ayudar?

La API REST admite:

operaciones de solo lectura, es decir, solo SELECTconsultas SQL
Proyecciones parciales XP (p /persons?fields=firstname,lastname. Ej. )
Restricciones de RSQL ( /persons?query=firstname==John;department.code==42ver otros ejemplos ).

Algunas referencias entre tablas (claves foráneas) se representan como atributos en la API REST (como Person.departmenten el ejemplo de restricciones anterior), pero algunas referencias se representan como subrecursos (por ejemplo /persons/{userName}/projects). Esto significa que algunas consultas requieren diseñar "un plan" para ser respondido en términos de solicitudes REST.

Por ejemplo: la consulta de "nombres de proyectos activos de Chuck Norris" se traduciría en:

/persons?query=firstname==Chuck;lastname==Norris
Obtener userNamedel resultado
/projects/{userName}?fields=name&query=state==ACTIVE

— Jakub Stejskal
fuente

Solo tengo curiosidad, ¿qué estás desarrollando? ;)

— Jakub Jirutka

@JakubJirutka Estoy tratando de construir una interfaz de lenguaje natural para la base de datos (NLIDB) sobre KOSapi. En realidad, iba a contactarlo con respecto a los detalles sobre RSQL, para poder agregar más información sobre mi proyecto, si está interesado.

— Jakub Stejskal

Al comienzo de la pregunta, dice que las consultas de los usuarios estarían en SQL o en un lenguaje de consulta similar, pero su ejemplo es "nombres de proyectos activos de Chuck Norris". ¿Es este un ejemplo real de lo que tendrías que analizar?

— Mike Partridge

Algo parecido a un archivo XML debe usarse para asignar llamadas REST a SQL. Por ejemplo, gist.github.com/d3ep4k/7da96e35bf778e69c53d

— Clasificador

Técnicamente, el lenguaje de consulta es solo otro estándar que el servicio REST debe entender. No es necesario asignar para consultar parámetros. Por ejemplo, por Hydra es posible definir un solo parámetro de consulta que contiene, por ejemplo, un SQL. Todo lo que necesita es un vocabulario en el que pueda describir SQL, y ofc un cliente que pueda construir SQL y un servidor que pueda entender SQL. El vocabulario común es el contrato entre el cliente y el servidor en este caso. Algunos hablan de esto. Para que no tenga que crear un lenguaje de consulta propio, puede reutilizar cualquier lenguaje de consulta existente ...

WADL y otros lenguajes de descripción REST son un mal comienzo, porque REST tiene una restricción uniforme de interfaz / HATEOAS que establece que los clientes tienen que usar hipervínculos para cambiar su estado. Los clientes deben decidir qué hipervínculo elegir al verificar su semántica. Los metadatos de enlace (por ejemplo, relación de enlace) contienen esa semántica ... Por idiomas como WADL no hay enlaces, metadatos de enlace o semántica, por lo que el cliente REST no se puede reutilizar, ya que no está desacoplado del servicio REST. : S

— inf3rno
fuente