Computación avanzada en java cert

Servicio de asesoría y resolución de ejercicios [email protected]

www.maestronline.com

Solicita una cotización a través de nuestro correo

Maestros Online

Computación

avanzada en JAVA

Apoyo en

ejercicios

Servicio de asesorías y solución de ejercicios

[email protected]



Instalación de Tomcat

1. De acuerdo al sistema operativo objetivo, obtener el paquete de instalación para

Tomcat v8.0 de http://tomcat.apache.org/download-80.cgi

2. Descomprimir el archivo de instalación o ejecutar el instalador.

3. Investigar cómo iniciar/detener Tomcat además de los scripts

startup.sh/shutdown.sh, startup.bat/shutdown.bat y como servicio en Windows.

4. Documentar instalación con capturas de pantalla.

Cambio de Puerto de 8080 a 9090 y agregar usuario admin

1. Investigar cómo cambiar el puerto por defecto (8080).

a. Modificar el puerto por defecto al puerto 8090.

2. Investigar como agregar usuarios y roles.

a. Agregar rol manager-ui.

b. Agregar usuario admin con el rol manager-ui asignado.

3. Documentar instalación con capturas de pantalla.

Integrar Eclipse con Tomcat

1. Definir el servidor previamente instalado en Eclipse.

2. Crear un Dynamic Web Application y asignar el servidor Tomcat v8.0 previamente

definido en Eclipse.

3. Compilar y ejecutar la Web Application.

4. Documentar con capturas de pantalla.

Crear un archivo WAR del código incluido en el tag v1.2.6

1. Clonar el repositorio de github: https://github.com/jm66/CS13304

2. Cambiar al tag v1.2.6

3. Importar proyecto a Eclipse IDE.

4. Ajustar el Runtime Environment: JRE y Apache Tomcat.

5. Investigar cómo exportar código a un archivo WAR.


Hacer el deployment con Tomcat Manager

1. Acceder a Tomcat Manager disponible en http://localhost:8090/manager/html con

el usuario admin previamente creado.

2. Hacer el deployment de la aplicación.

3. Acceder a la aplicación para validar deployment.


Tomando en cuenta el último ejemplo del tema donde se demuestra como subir archivos del

cliente al servidor, investigar el método para transmitir archivos por medio de HTTP desde el

servidor al cliente. Esto incluye los streams de entrada y salida, Headers utilizados para que el

navegador entienda que se está transfiriendo un archivo y qué tipo de archivo.

Utilizar el código fuente del tag v1.3.8, donde se incluyen dos Servlets: DownloadServlet.java

y UploadServlet.java; Files.html para incluir las formas y la estructura de web app.

En la clase UploadServlet.java no es necesario modificar, pues funciona tal como se explicó

anteriormente

En el archivo WebContent/Files.html:



1. Crear un nuevo formulario para descargar un nombre de archivo dado. El formulario

contará con los siguientes elementos:

a. Identificador “download”

b. Acción “DownloadServlet”

c. Método “GET”

d. Un elemento input de tipo text con nombre fileName y un placeholder con

valor de archivo.ext

e. Un elemento input de tipo submit con texto Descargar

2. El diseño debe lucir como la siguiente imagen:

El deployment descriptor (web.xml):

1. Definición del Servlet DownloadServlet con la clase me.jmll.DownloadServlet.

2. Definición de servlet mapping para DownloadServlet como /Download y

/DownloadServlet

3. Definición de Context Init Params

a. Nombre: pathDestino

b. Valor: <Path destino donde se subirán los archivos>

En la clase DownloadServlet:

1. El método HTTP POST no será permitido, por tanto si se accede al DownloadServlet

con el método POST debe de responder con un HTTP estatus 405. Método No

Permitido.

2. El método HTTP GET será el único permitido para descargar archivos, por tanto

doGet() llamará a doRequest(), el cual cuenta con la lógica de negocio deseada para

enviar archivos al cliente.

3. En el método doRequest()

a. Obtener primero el parámetro fileName enviado en la solicitud.

b. Si no existe, responder la solicitud con un HTTP status 400.

c. Obtener el contexto del servlet en la variable servletContext.

d. Obtener el context init param pathDestino y crear el path completo para el

archivo que se va a descargar.

e. En el Try-With-Resources y dentro de los recursos, crear instancias

de FileInputStream a partir del archivo a descargar y OutputStream a partir del

objeto Response.

f. Obtener el MIME Type del archivo a descargar, en dado caso que no se pueda

descargar, hacer por defecto que sea “application/octet-stream”.

g. Asignar el MIME Type a la respuesta HTTP, además de incluir la longitud de la

respuesta mediante el método length() del archivo a descargar.

h. Configurar el response Header “Content-Disposition” como attachment y el

nombre del archivo. Se sugiere investigar la forma en que operan.



i. Si no existe el archivo, responder con un HTTP status 404.

4. Investiga qué es Twitter Bootstrap y cómo se puede integrar con una web app.

(http://getbootstrap.com/)

a. Ten a la mano la documentación de su CSS, JS y componentes.

5. El contenido de la web app Administrador de Archivos parte del tag v1.4.3 del

repositorio del curso cuenta con lo siguiente:

Dentro del código de fuente de los Servlets se encuentran dos paquetes, me.jmll.* y

me.jmll.io. El paquete me.jmll.io cuenta con una clase NIO2RecursiveDir.java, el cual es

encargado de buscar recursivamente el contenido de un directorio específico tipo Path.

Las clases AdminArchivos, DescargaArchivo y ListaArchivos dentro del paquete

me.jmll.* son los elementos que serán corregidos para su correcto funcionamiento.

Se incluyeron también librerías para el uso de tag-libraries en WEB-INF/lib.

WEB-INF/views cuenta con los archivos JSP para mostrar información y el archivo

index.jsp redirecciona a al URI /Admin.do que es el url mapping del servlet

AdminArchivos.

6. Dentro del archivo WEB-INF/includes/Bootstrap.jsp deben de ir los recursos

relacionados con Twitter Bootstrap necesarios para mostrar el contenido utilizando

este Framework.

a. Estos recursos deben de ser entregados por medio de un CDN (Content

Delivery Network).

b. El archivo Deben WEB-INF/includes/Bootstrap.jsp debe ser incluidos en el

tag <header> de HTML de WEB-INF/views/DifForm.jsp y WEB-INF/

views/DirView.jsp

7. En el servlet me.jmll.ListaArchivos:

a. Utilizando java.nio.Path crea un objeto basado en el parámetro obtenido

“path”.

b. Crea un objeto de tipo List que almacene objetos de tipo java.nio.Path y

sea ArrayList. Este elemento almacenará los resultados

de NIO2RecursiveDir.



c. Valida que exista el objeto Path creado en el paso 3(a) exista y sea directorio

para llamar a NIO2RecursiveDir.walkdir() y obtén los resultados en la lista

creada en el paso 3(b).

d. De lo contrario, un error será agregado a la lista errores definida al inicio, el

cual será necesario agregar como atributo al request con el nombre “errores”.

e. Obtén el RequestDispatcher con “/WEB-INF/views/DirView.jsp” y reenvía

con el método forward.

8. En el servlet me.jmll.AdminArchivos:

a. Obtén el atributo “errores” de la request para después asignarlo una vez más a

la nueva request.

b. Obtén el RequestDispatcher con “/WEB-INF/views/DirForm.jsp” y reenvía

con el método forward.

9. En el JSP /WEB-INF/views/DirForm.jsp

a. Con ayuda de la documentación de Twitter Bootstrap, haz que el

campo path sea requerido.

b. Con ayuda de la documentación de Twitter Bootstrap, crea un botón de tipo

submit que tenga el texto “Listar” y el ícono “glyphicon-search”.

c. Tomando en cuenta que se cuenta con un atributo de solicitud

llamado errores, investiga el uso del tag <c:forEach> e imprime los errores

con JSP Expression Language.

10. En el JSP /WEB-INF/views/DirView.jsp

a. Con ayuda del tag <c:if> y ${fn:lenght() lt 1} valida si el objeto en el

atributo paths cuenta con menos de un elemento.

b. Con el tag <c:forEach> genera las filas de la tabla con

el nombre del elemento, el path, y el tamaño. Toma en cuenta que cada uno

de los elementos es de tipo java.nio.Path, y puedes acceder a sus métodos tal

como lo menciona la documentación.

11. La clase DescargaArchivo es el resultado de DownloadServlet de la Actividad 1

del Tema 3.

12. Investiga qué es Twitter Bootstrap y cómo se puede integrar con una web app.

(http://getbootstrap.com/)

a. Ten a la mano la documentación de su CSS, JS y componentes.

13. Investigar cómo cargar Resource Bundles (java.util.ResourceBundle) en Servlets

basados en locales (java.util.Locale).



14. El contenido de la web app Administrador de Archivos, parte del tag v1.5.7 del

repositorio del curso cuenta con lo siguiente:

15. En la actividad del tema anterior no se utilizaron elementos de Bootstrap que

requerían JQuery para su funcionamiento, por tanto dentro de WEB-

INF/BootstrapJS.jsp se debe:

a. Agregar la versión 1.11.3 de JQuery para que los elementos del UI de esta

nueva versión funcionen correctamente. El recurso debe ser proporcionado por

una CDN, no local.

b. Tal como lo recomienda Twitter Bootstrap, estos recursos JS se recomiendan

ser cargados al final de la página, por tanto, en los archivos DirForm.jsp y

DirView.jsp requieren ser importados donde se indica.

16. El paquete me.jmll.i18n cuenta con dos recursos necesarios para internacionalizar la

web app, uno en inglés y otro en español. Cada uno con 20 llaves que serán ubicadas

a lo largo de la web app en JSP y servlets.

a. DirForm.jsp, DirView.jsp: validar que el parámetro locale se encuentre en la

solicitud, de lo contrario, validar si la variable locale está vacía y asignar ese

valor; de lo contrario, asignar el valor pageContext.request.locale a la variable

de session (scope=”session"). El tag a usar es <c:set var=”locale”

value=”${expresión}”/>

b. DirForm.jsp, DirView.jsp: con el tag <fmt:setLocale> asignar el valor de la

variable previamente configurada en la sesión (scope=”session")

c. DirForm.jsp, DirView.jsp: cargar bundle me.jmll.i18n.app en la variable

appBundle con el tag <fmt:setBundle>

d. DirForm.jsp, DirView.jsp: de acuerdo al video de lo esperado en la aplicación,

utilice el tag <fmt:message> correctamente para mostrar los mensajes dentro

de los bundles app.properties y app_es.properties.

e. ListaArchivos.java y DescargaArchivo.java de acuerdo con la investigación

de cargar atributos de sesión y ResourceBundle en Servlets, crea

un Locale a partir del

atributo request.getSession().getAttribute("locale"), para después cargar

ese Locale con el método getBundle de ResourceBundle.

f. ListaArchivos.java y DescargaArchivo.java: internacionaliza mensajes y

errores también dentro de los servlets.

17. Descargar el código fuente del tag v1.6.3.

18. Renombrar el tag file creado previamente de WEB-

INF/tags/bootstrap/content.tag a WEB-INF/tags/bootstrap/base.tag y realizar los

cambios necesarios para que pueda ser referido como <b:base> en un JSP.

19. Crear un tagfile parte de WEB-INF/tags/bootstrap/ llamado container.tag y que

pueda realizar la función de <div class=”container|container-fluid”> el tag debe un

atributo: fluid de tipo Boolean para en caso de especificarlo como válido, se debe



crear el div con la clase container-fluid, de lo contrario, se debe crear el div con la

clase container. Este tag contará con cuerpo.

20. Crear un tagfile WEB-INF/tags/bootstrap/ llamado pageHeader.tag, el cual se

encargará de crear un <div> con la clase page-header con dos

atributos: title ysubTitle de tipo String, el primero requerido y el segundo no. Este tag

no tendrá cuerpo.

21. Crear un tagfile WEB-INF/tags/bootstrap/ llamado jumbotron.tag que contará con un

atributo title requerido y el cuerpo del tag será mostrado como el contenido de texto

del elemento <div class=”jumbotron”>.

22. Crear un tagfile WEB-INF/tags/bootstrap/ llamado alert.tag, el cual contará con tres

atributos type (String), dismissable (Boolean) y fadeIn (Boolean). El

atributotype especificará el tipo de alerta (warning, danger, info, success). El

atributo dismissable especificará si el botón podrá ser cerrado y fadeIn indicará si un

efecto de difuminación se agregará.

23. El contenido de index.jsp no se modificará pues será la forma de validar si los tag files

fueron creados exitosamente:

24. Al crear cada uno de estos tags bajo el nombre correcto y hacer el deployment de la

aplicación, se tendrá que observar algo como se muestra en la siguiente imagen o en

el video adjunto:

25. La actividad la componen 3 Servlets: Login, Logout y Session, además de un POJO

User que simulará entradas en una base de datos por medio de HashMap.

26. POJO User cuenta con tres atributos de tipo String: username, password y fullName.

Cree los getters/setters y constructor con atributos username y password.

27. Servlet Login Método init():

a. Creará un objeto de tipo Map llamado DB, el cual estará compuesto de String

como llaves y me.jmll.model.User como valor.

b. Validará que exista el atributo “DB” en el contexto del servlet ServletContext. Si

no existe creará una instancia de HashMap<String, User> referenciado a DB.

c. Se crearán los siguientes usuarios para inicializar la base de datos:

User user1 = new User("anakin", "deathStar2");

user1.setFullName("Anakin Skywalker");



User user2 = new User("kenobi", "starfighter");

user2.setFullName("Obi Wan Knenobi");

d. Posteriormente a la creación de usuarios, se generará un evento DEBUG

utilizando el Logger log inicializado en el servlet comentando que se han

creado usuarios.

e. Después se guardará en el contexto del Servlet ServletContext el atributo DB.

f. Si existe, referenciará el objeto del ServletContext a la variable DB.

g. Generará un evento INFO con el Logger log previamente inicializado.

28. Servlet Login Método doGet(): obtendrá el request dispatcher y enviará la solicitud

a /WEB-INF/views/session.jsp si el atributo de la sesión user no es nulo. De lo

contrario, llamará al método doPost()

29. Servlet Login Método doPost():

a. Validará que los parámetros de la solicitud inputPassword e inputUsername no

sean nulos, de lo contrario, agregará un elemento string a la lista errores con el

mensaje “You should login first. Registrará un evento WARN con el log con el

mismo mensaje y reenviará a /WEB-INF/views/login.jsp utilizando el

requestDispatcher.

b. Si el usuario no es nulo, asigna el atributo user a la sesión con el valor de

getUsername y crea un Cookie llamado fullName con el valor de getFullName.

30. Servlet Login Método login():

a. El método valida que el usuario y que el password no sean nulos; de ser nulo,

regresa un valor nulo.

b. Obtiene el atributo DB del ServletContext, y lo referencia a la variable DB para

posteriormente validar la existencia del usuario en cuestión utilizando el

método get (username) de la clase HashMap.

31. Servlet Logout:

a. El método doGet obtiene el atributo de la sesión user, el cual si existe utiliza el

método removeAttribute() de la sesión para eliminarlo, posteriormente busca

entre las Cookies la llamada fullName para asignarle un valor nulo y maxAge

de 0. Finalmente se invalida la sesión con el método invalidate().

32. Log4j2: se agregan tres loggers, uno por cada clase con referencia al appender

LogFile

Investigación



1. Investiga sobre Rate Limiting Patterns, los Headers y el Status Code que se

manejan en la Response.

2. Investiga cómo se definen los parámetros de inicio en Filters y cómo pueden ser

cargados desde el Filter.

Desarrollo

1. Crear un Filter llamado RateLimit dentro del paquete me.jmll.filter.

2. Definir el Filter en el deployment descriptor para filtrar solicitudes hacia URL con

extensión CSS.

3. Agregar dentro de la definición de los parámetros del Filter dos

elementos REQ_LIMIT y TIME_LIMIT. El primero maneará la cantidad de solicitudes

recibidas y el segundo controlará el periodo de tiempo en que las solicitudes sean

recibidas.

4. En la clase RateLimit definir:

a. La variable logger de tipo org.apache.logging.log4j.Logger con los

modificadores de acceso necesarios para obtener por medio

deorg.apache.logging.log4j.LogManager el logger para la clase en cuestión.

b. La variable req_limit de tipo Integer con modificador de acceso privado y

valor de 5.

c. La varaible time_limit de tipo Integer con modificador de acceso privado y

valor de 15000.

d. Una constante de tipo String llamada REQ_LIMIT con valor de un String

“REQ_LIMIT”.

e. Una constante de tipo String llamada TIME_LIMIT con valor de un String

“TIME_LIMIT”.

f. Tres constantes de tipo String con modificador de acceso

privado XRATE_LIMIT, XRATE_LIMIT_REMAINING y XRATE_LIMIT_RESET, la

s cuales concentran el valor en string de los headers apropiados.

5. En la clase RateLimit crear:

a. Dentro del método encargado de cargar la configuración definida en el

deployment descriptor, agregar las líneas para

cargar REQ_LIMIT y TIME_LIMIT y sus valores asignarlos a req_limit y time_limit

respectivamente.

6. En la clase RateLimit dentro del método doFilter:

a. Realiza el casting de request y response

a HttpServletRequest y HttpServletResponse.

b. Agregar el header definido en XRATE_LIMIT a la response.

c. Si es que ha excedido el número de solicitudes en el periodo agregar el

header. XRATE_LIMIT_RESET y el código de estado HTTP correcto para

especificar que han sido muchas solicitudes.

d. Establecer el encoding de la respuesta en UTF-8.

7. En el archivo de configuración log4j2.xml agregar el

filter me.jmll.filter.RateLimit para que utilice LogFile.



8. Después de agregar lo antes definido, se debe esperar un resultado de acuerdo al

video de la actividad.

El participante creará cuatro recursos REST utilizando Spring Framework, el patrón de

diseño Model-View-Controller y Controller-Service-Repository. Los recursos se

encargarán de enumerar los archivos en un directorio en específico, descargar, subir y

borrar archivos, enviar notificaciones por medio de eventos asíncronos, siguiendo los

principios del Richardson Maturity Model. La evidencia consiste en 2 entregables, que se

describen a continuación: Avance 1 de la evidencia. Ambiente de desarrollo y

requerimientos. Entrega final de la evidencia. Diseño, programación y

Ambiente de desarrollo Como parte de la primer entrega, debes crear tu ambiente de

desarrollo donde desarrollarás el programa RESTfulWS. Instalar JDK 8 en su versión más

reciente. Instalar el web container de tu preferencia (Tomcat, Glassfish, u otro), toma en

cuenta que Tomcat es el que se indagará en el curso. Crear una cuenta en GitHub como

usuario normal o estudiante (con tu cuenta de correo https://education.github.com/).

Instalar GitHub para Escritorio o Git en línea de comando. Instalar un IDE de acuerdo a

los mencionados (Eclipse, NetBeans, IntelliJIDEA). Crear un repositorio en GitHub con tu

cuenta bajo el nombre de RESTfulWS, por ejemplo https://github.com/jm66/RESTfulWS,

con los siguientes requerimientos: 1. Archivo README.md con las siguientes secciones: a)

Instalación b) Uso c) Créditos d) Licencia 2. Archivo .gitignore para ignorar los archivos

.class, .swp y los archivos de proyecto de tu IDE seleccionado. Por ejemplo, eclipse:

.project, .metadata, etc. 3. Crear un branch llamado develop donde se registrarán todos

los cambios en tu código. Por ejemplo, https://github.com/jm66/RESTfulWS/network •

Configurar el IDE instalado para manejar tu repositorio en GitHub. Una vez completado

este punto incluirás el link de tu repositorio, donde se recibirá el código en la entrega

final. Proyecto Maven En el curso se utilizará Maven para el manejo de dependencias a

partir del módulo tres, sin embargo es un requisito para la evidencia. Por lo tanto, el

segundo commit del branch "develop" es la estructura de un proyecto Maven, debe

investigarse cómo crearlo de acuerdo al IDE seleccionado, el cual debe incluir al menos los

siguientes puntos: 1. Código fuente dentro de "src/main/java" 2. Recursos utilizados por

el código fuente "src/main/resources" 3. Código fuente de pruebas y recursos de prueba

dentro de "src/test/java" y "src/test/resrouces". 4. Archivo pom.xml con los siguientes

elementos: a. La definición de las siguientes propiedades: Propiedad Valor java-version

1.8 org.springframework-version 4.2.5.RELEASE org.aspectj-version 1.6.10

jackson.version 2.4.2 log4j.version 2.0.2

La definición de las siguientes dependencias: Group Id Artifact Id Version Scope Others

org.aspectj aspectjrt ${org.aspectjversion} org.apache.commons commonslang3 3.3.2

compile org.apache.logging.log4j log4j-api ${log4j.version} compile

org.apache.logging.log4j log4j-core ${log4j.version} runtime org.apache.logging.log4j

log4j-jcl ${log4j.version} runtime org.apache.logging.log4j log4j-slf4jimpl

${log4j.version} runtime javax.inject javax.inject 1 javax.validation validation-api 1.0.0.GA



com.fasterxml.jackson.core jackson-core ${jackson.versio n} compile

com.fasterxml.jackson.core jacksonannotations ${jackson.versio n} compile

com.fasterxml.jackson.core jacksondatabind ${jackson.versio n} compile

com.fasterxml.jackson.datat ype jacksondatatypejsr310 ${jackson.versio n} compile

javax.servlet javax.servletapi 3.1.0 provided javax.servlet.jsp javax.servlet. jsp-api 2.3.1

provided javax.el javax.el-api 3.0.0 provided javax.servlet.jsp.jstl javax.servlet. jsp.jstl-api

1.2.1 compile javax.annotation javax.annotat ion-api 1.2 compile junit junit 4.7 test

org.glassfish.web javax.servlet. jsp.jstl 1.2.2 compile Exclude: javax.servlet; servlet-ap

javax.servlet.jsp; jsp-api javax.servlet.jsp.jstl; jstlapi org.springframework springcontext

${org.springfram ework-version} org.springframework springwebmvc ${org.springfram

ework-version} org.springframework spring-oxm ${org.springfram ework-version}

compile org.springframework springcontextsupport ${org.springfram ework-version} c. La

definición de la siguiente configuración de build: i. Source Directory: src/main/java ii.

Resource: src/main/resources iii. Test Source Directory: src/test/java iv. Test Resource:

src/test/resources d. La propiedad URL debe ser el URL del repositorio de GitHub

previamente creado. e. La definición de los siguientes plugins:

maven-eclipseplugin 2.9 org.springframework.ide.ec lipse.core.springnature

org.springframework.ide.e clipse.core.springbuilder true true org.codehaus.mojo exec-

mavenplugin 1.2.1 org.test.int1.Main org.apache.maven.plu gins maven-war-plugin 2.3

src/main/webapp org.apache.maven.plu gins maven-compilerplugin 3.1 1.8 1.8 Analizar

los siguientes requerimientos El producto final serán unos RESTful Web Services que

provean las siguientes funcionalidades: Recurso para descargar, subir y borrar archivos

especificados en el parámetro path por medio de los métodos GET, POST y DELETE,

respectivamente. Recurso para listar contenidos de un directorio en específico por medio

del parámetro dir. Los archivos listados generan un link para su descarga por medio del

recurso file/. Recurso para crear (enviar) y listar el registro de las notificaciones.

Recurso para obtener colección usuarios. Recurso principal el cual contiene los recursos

disponibles: user, directory, file, notify. Puntos adicionales: La aplicación contará con un

log donde se registrarán las actividades de la aplicación en sus diferentes niveles. La

aplicación será totalmente portable, es decir, que se podrá ejecutar en cualquier sistema

operativo que tenga instalado Java8. La aplicación contará con las dependencias

incluidas por Maven, por tanto, sólo con hacer el deployment del WAR se podrá ejecutar

sin necesidad de descargar librerías adicionales. La aplicación contará con el correcto

manejo de recursos y excepciones, es decir, si ocurre una excepción, el programa no

saldrá, sino que seguirá ejecutándose y mostrará el mensaje de error en la pantalla. La

descripción de requerimientos es sólo con propósitos informativos, pues más adelante se

podrán analizar a profundidad.

A continuación se describen las instrucciones para la entrega final: La estructura del

código del proyecto final se basará en la contenida en la práctica del tema 12, Hypermedia

control en RESTful Web Services, donde hasta este punto se habrá elaborado al menos el



recurso user y se tendrá conocimiento de patrones de diseño MVC y CSR, además de los

principios REST y el modelo de madurez de Richardson, este último resalta la importancia

de Hypermedia control en los recursos de los Web Services RESTful. Tal como se mencionó

en los requerimientos, los RESTful Web Services residirán en el mapping /api/v1/ y

tendrán los siguientes recursos y métodos HTTP disponibles (esto deberá incluirse en la

documentación wiki del repositorio): Recurso Mapping Descripción GET POST PUT DELETE

OPTIONS file /api/v1/file/ Subir, descargar, borrar archivos. Si Si No Si Si directory

/api/v1/dire ctory/ Listar archivos contenidos en un directorio. Si No No No Si notify

/api/v1/notif y/ Crear y listar notificaciones. Si Si No No Si user /api/v1/user / Crear,

listar, actualizar, borrar usuarios. Si Si Si Si Si index /api/v1/ Listar los recursos

disponibles en el api. Si No No No No

Para cada recurso se creará un branch en GitHub a partir de develop con la base de la

práctica el tema 12 como se muestra a continuación: A través del desarrollo cada uno de

los recursos hará merge con el branch develop cuando esté listo y aquellos dependientes

como directory y file podrán ser un solo branch, pero se recomienda que sea

independientes. Para más información acerca de operación de git, se recomienda ir al sitio

oficial https://git-scm.com/ Finalmente, cuando se haga el merge de develop con el

branch master para la versión final, esta también será identificada con un tag en la versión

estable, por ejemplo, v1.0. Curso: Computac

Education

Computación avanzada en java cert