Diseño de interfaz en línea: cómo diseñar un proyecto de interfaz de forma correcta y razonable

Cómo diseñar la interfaz común de App y Web

1 Determinar el método GET o POST de MVC en la definición de la interfaz

Desde toda nuestra plataforma WebAPI. se basa en el desarrollo de API se basa en MVC. Por lo tanto, al definir toda la interfaz WebAPI, generalmente es necesario declarar explícitamente que la interfaz es [HttpGet] o [HttpPost]. Aunque algunas interfaces no necesitan declararse, los errores son similares. Se puede evitar lo siguiente; la declaración explícita sigue siendo beneficiosa.

El recurso solicitado no admite el método http "POST"

Por ejemplo, la interfaz del objeto de búsqueda definida en la clase base es la siguiente.

/ //

///Consulta la base de datos para comprobar si hay un objeto con el ID especificado

///

/// El valor de ID del objeto

///Devuelve el objeto especificado si existe; de ​​lo contrario, devuelve Null

[HttpGet]

publicvirtualTFindByID(stringid, stringtoken)

Si se agrega, elimina o modifica una interfaz, generalmente debe declararse como método POST para enviar datos y, según consideraciones de seguridad, debe llevar más parámetros

///

///Inserte el objeto especificado en la base de datos

///

///El objeto especificado

///Si el la operación fue exitosa

[HttpPost]

publicvirtualCommonResultInsert(Tinfo, stringtoken, stringsignature, stringtimestamp, stringnonce, stringappid)

2. objetos dinámicos

En la interfaz general de WebAPI, podemos encontrar muchos parámetros de tipo simples, pero queremos que envíen datos en modo POST, entonces podemos tener dos métodos para manejarlos. Uno es definir un. class para colocar estos parámetros, y el otro es usar parámetros dinámicos de JObject. Hay muchas diferencias en el primero. Conveniente, porque es imposible definir una clase de entidad más para cada parámetro de interfaz, por lo que puede haber muchas definiciones de clase. Es difícil de administrar, por ejemplo, el siguiente es un caso de la interfaz de llamada de la API de WeChat, y también necesitamos establecer dichas reglas de procesamiento

Descripción de la solicitud de llamada de la interfaz

método de solicitud http: POST (use el protocolo https)

Formato de datos POST: json

Ejemplo de datos POST:{"group":{"id":108,"name":"test2_modify2"} }

Entonces, ¿qué sucede cuando usamos JObject? Veamos la definición y el código de procesamiento de la interfaz JObject. ¿Es un objeto bajo el espacio de nombres?

///

///Cambiar contraseña de usuario

///

/// Objeto compuesto que contiene nombre de usuario y contraseña de usuario

///Token de acceso de usuario

// /

[HttpPost]

publicCommonResultModifyPassword(JObjectparam,stringtoken)

{

// Comprobación de token , si falla, se lanzará una excepción

CheckResultcheckResult=CheckToken(token);

dynamicobj=param;

if(obj!=null)

{

stringuserName=;

stringuserPassword=;

boolsuccess=BLLFactory.(userName,userPassword);

returnnewCommonResult(success);

}

else

{

thrownewMyApiException("Se produjo un error al pasar parámetros" );

}

}

Cuando convertimos el objeto JObject en el objeto que necesitamos, debido a que no definimos una clase de entidad específica, usamos Dynamic. La sintaxis declara que se trata de un objeto dinámico y las propiedades correspondientes se obtienen en tiempo de ejecución.

dynamicobj=param;

De esta manera, podemos PUBLICAR dinámicamente el objeto JSON correspondiente en la interfaz WebAPI al llamar, sin tener que predefinir clases para varios parámetros de la interfaz.

///

///Llame a la interfaz WebAPI y cambie la contraseña de usuario

///

///Nombre de usuario

///Contraseña modificada

/ / /Si la modificación es exitosa, devuelve verdadero; de lo contrario, devuelve falso

publicboolModifyPassword(stringuserName,stringuserPassword)

{

varaction ="ModificarContraseña" ;

varpostData=new

{

nombre de usuario=nombre de usuario,

contraseña de usuario=contraseña de usuario

}.ToJson ();

stringurl=GetTokenUrl(action);

CommonResultresult=JsonHelper.ConvertJson(url,postData);

return (resultado!= null)?:false;

}

GetTokenUrl construye una dirección de envío completa basada en parámetros como el token y la dirección API. Pasamos el código anterior

varpostData=new

{

userName=userName,

userPassword=userPassword

}.ToJson();

Puede crear dinámicamente un objeto, generar su cadena JSON, enviar los datos POST a la interfaz API correspondiente y luego convertir el resultado en un objeto.

3. Procesamiento de recopilación y paginación

En muchas interfaces, necesitamos utilizar el procesamiento de paginación, y WebAPI no es una excepción, lo que puede mejorar la eficiencia de la recuperación de datos y reducir la presión del procesamiento de datos del servidor. al mismo tiempo que envía la velocidad de visualización de datos del cliente.

La definición de la interfaz de colección general es la siguiente (interfaz de clase base genérica).

///

///Devuelve la colección de todos los objetos en la base de datos

///

///Una colección de objetos especificados

[HttpGet]

publicvirtualListGetAll(stringtoken)

{

//Compruebe si el usuario tiene permiso; de lo contrario, se generará una excepción MyDenyAccessException

(,token);

Listlist=( );

returnlist;

}

Sin embargo, habrá muchos registros devueltos. Generalmente, se requiere paginación, por lo que la definición de la interfaz de procesamiento de paginación es. como sigue.

///

///Consulta la base de datos según las condiciones y devuelve una colección de objetos (para visualización de datos de paginación)

// /< /summary>

///Una colección de objetos especificados

[HttpPost]

publicvirtualPaggedListFindWithPager( stringcondition,PagerInfopagerInfo , stringtoken)

La interfaz de paginación utiliza una clase genérica PageList en los resultados devueltos aquí. Esto nos facilita obtener los registros actuales y el número total. Su definición es la siguiente.

///

///Colección de páginas

///

///< typeparamname="T">Objeto

publicclassPaggedList

{

///

///Devuelve el número total de registros

///

publicinttotal_count{get;set;}

///

///Colección de listas

///

publicListlist{get;set;}

}

Finalmente, toda la implementación de la interfaz WebAPI de procesamiento de paginación es la siguiente.

///

///Consulta la base de datos según las condiciones y devuelve una colección de objetos (para visualización de datos de paginación)

// /< /summary>

///Una colección de objetos especificados

[HttpPost]

publicvirtualPaggedListFindWithPager( stringcondition,PagerInfopagerInfo ,stringtoken)

{

//Compruebe si el usuario tiene permiso; de lo contrario, se generará una excepción MyDenyAccessException

(,token);

Listlist=(condition,pagerInfo);

//Construido en formato Json y pasado

varresult=newPaggedList(){total_count =,list=list} ;

returnresult;

}

El código WebAPI de paginación final del lado del cliente es el siguiente.

///

///Consulta la base de datos según las condiciones y devuelve una colección de objetos (para visualización de datos de paginación)

// /< /summary>

///Condiciones de consulta

///Entidad de paginación

///Una colección de objetos especificados

publicvirtualListFindWithPager(stringcondition,refPagerInfopagerInfo)

{

varaction="FindWithPager";

stringurl=GetTokenUrl(action)+("&condition={0}",condition);

varpostData=();

Listaresult=newList();

PaggedListlist=JsonHelper>.ConvertJson(url,postData);

if(list!=null)

{

=_count;//Modificar el número total de registros

result=;

}

returnresult;

}

4. La interfaz del marco híbrido integra la interfaz WebAPI

Construida en su totalidad. Plataforma WebAPI y en el marco híbrido Durante el proceso de integración, desarrollé e integré cada módulo de manera relativamente independiente. Se logró la unificación de varios métodos, incluido el acceso directo a la base de datos, la obtención de datos a través de servicios WCF y la obtención de datos a través de WebAPI. convocatorias, consiguiendo así un alto grado de integración en todo el marco híbrido.

El núcleo de todo el marco híbrido es integrar varios módulos reutilizables de una manera relativamente independiente. Podemos construir rápidamente una plataforma de aplicaciones unificada sobre una base determinada.

Se ha creado toda la plataforma WebAPI, incluido el contenido del lado del servidor, y la interfaz WebAPI correspondiente se lanza en forma de controlador API.

En cada módulo independiente del marco híbrido, encapsulamos el procesamiento de llamadas del cliente WebAPI correspondiente, implementando así el método de llamada WebAPI.

En Win10, use el modo WebAPI para ejecutar el marco híbrido y el efecto de interfaz principal obtenido es el siguiente.

La interfaz del sistema de gestión de permisos del módulo independiente es la siguiente.

La serie de artículos es la siguiente:

Aplicación de la arquitectura de aplicaciones WebAPI en el marco híbrido Winform (1)

Aplicación de la arquitectura de aplicaciones WebAPI en el marco híbrido Winform (2)--Manejo de resultados anormales personalizados

Resumen de la experiencia de diseño de la interfaz WebAPI

Aplicación de la arquitectura de la aplicación WebAPI en el marco híbrido Winform (3)--Interfaz Winfrom que llama a la descomposición del proceso WebAPI

Aplicación de la arquitectura de aplicaciones WebAPI en el marco híbrido Winform (4): utilice herramientas de generación de código para desarrollar rápidamente un conjunto completo de aplicaciones

Aplicación de la arquitectura de aplicaciones WebAPI en el marco híbrido Winform (5) ) - ¿Cómo lidiar con la coexistencia de diccionarios a nivel de sistema y diccionarios a nivel de empresa? ¿Cómo diseñar la interfaz API? ¿Se requiere autenticación al solicitar la interfaz para evitar que terceros llamen a la interfaz a voluntad?

Cómo utilizar la interfaz:

1. La persona que llama a la interfaz primero solicita la asignación de un ID de cliente, un secreto de cliente y proporciona al proveedor de la interfaz (servidor) una URL de devolución de llamada accesible (utilizada para la interfaz access_token).

2. La persona que llama a la interfaz utiliza clientid y clientsecret como parámetros para enviar una solicitud al proveedor de la interfaz.

El proveedor de la interfaz accede a la callbackURL y envía access_token (hay un límite de tiempo y se volverá a adquirir después del tiempo de espera).

3. La persona que llama a la interfaz utiliza access_token como parámetro para llamar a otras interfaces y obtener información relevante.

4. La persona que llama a la interfaz vuelve a obtener el token de acceso después de que se agote el tiempo de espera.

Tengo una pregunta:

¿Es necesario este complejo mecanismo solo para evitar que usuarios ilegales utilicen la interfaz a voluntad?

La interfaz utiliza una conexión https para garantizar confidencialidad de datos sexo.

Entonces, ¿es posible simplificar el proceso anterior y configurar solo un token de acceso en el servidor de interfaz?

Los usuarios de la interfaz solo necesitan proporcionar el token de acceso correcto para usar otras interfaces normalmente. Cómo diseñar un proyecto de interfaz de forma correcta y razonable

Comprender el prototipo es en realidad más para ayudarle a diseñar los datos y la estructura que se deben proporcionar al diseñar la interfaz. Pero a veces no tienes un prototipo cuando diseñas, por lo que esto no es un requisito. Pero si el prototipo aparece después de diseñar la interfaz, también podemos usarlo para verificar si el diseño de la interfaz es correcto y razonable.