Proyecto certificador de contenidos: Servicio web vía API de alta disponibilidad con phalconPHP y MongoDB

NativeAD, primera empresa de publicidad nativa en España busca proveedores para externalizar un proyecto de certificación de contenidos. El proyecto consta de hasta 5 fases, con distintos timmings, entregables y complejidad. En este primer alcance se busca desarrollar el core del producto, un servicio web via API RESTFul. Entregable FASE 1. Tiempo estimado entrega 2 semanas Definición para solicitar presupuestos Desarrollo servicio web API RESTFul de alta disponibilidad en phalconPHP + MongoDB. Integrando autenticación peticiones con OAuth 2.0, esto requiere un sistema de registro de aplicaciones y autorización de usuarios. Web API Endpoint Reference [login to view URL] Métodos 1) POST - URL del recurso /v1/certificate/[login to view URL] Información del Recurso Formato: json Requiere autenticación: sí Existencia de límites/quotas: sí. Parámetros title - Required summary - optional thumb - optional caption - optional Resultado de ejemplo: { "success": true, "message": "message goes here", "rate": null } 2) POST - URL del recurso /v1/certificate/[login to view URL] Información del Recurso Formato: json Requiere autenticación: sí Existencia de límites/quotas: sí. Parámetros title - required summary - required images - optional contentType - required content - required Resultado de ejemplo: { "success": true, "message": "message goes here", "rate": null } El servicio web, deberá poseer una librería que ejecute una batería de comprobaciones para la certificación del contenido. La definición de las validaciones será dada por el cliente y el proveedor tendrá que desarrollar la lógica para incluirla en los métodos de la API. La librería deberá estar lo más desacoplada posible para que en el caso de que se hagan cambios en la lógica de negocio, no afecte al funcionamiento del servicio. El registro de las aplicaciones que usarán en el sistema OAuth, en esta primera fase del proyecto será manual, o a través de un simple formulario protegido con usuario y contraseña y accesible desde determinadas IPs. Incluir la arquitectura de BBDD propuesta en el diagrama expuesto anteriormente. Si fuera necesario proponer mejoras en la arquitectura. Las aplicaciones serán registradas en la tabla “applications”, serán las que tengan autenticación mediante OAuth. Una aplicación pertenece a un cliente y un cliente puede tener n aplicaciones. Un cliente puede tener reglas de validación ad-hoc para sus contenidos.