Diferencia entre revisiones de «PHP Servizos Web»
Ir a la navegación
Ir a la búsqueda
Línea 145: | Línea 145: | ||
=== Rutas === | === Rutas === | ||
− | * | + | * <u>Nota:</u> Lembrar que nun servizo non existen formularios de entrada de datos, polo que as rutas/funcións que dan acceso a ditos formularios sobran. |
+ | |||
+ | * Partimos da idea de que un perfume sempre vai pertencer a unha marca e polo tanto non existe se non existe a marca. | ||
+ | |||
+ | |||
+ | * As rutas que imos ter van ser: | ||
+ | |||
+ | :* '''POST''' http://meusitio.es/marcas → Para crear unha marca | ||
+ | :* '''GET''' http://meusitio.es/marcas/{marcas} → Para obter a información dunha marca concreta | ||
+ | :* '''PUT''' http://meusitio.es/marcas/{marcas} → Para modificar os datos dunha marca concreta | ||
+ | :* '''DELETE''' http://meusitio.es/marcas/{marcas} → Para eliminar unha marca concreta | ||
+ | :* '''GET''' http://meusitio.es/marcas → Para obter o listado de marcas. | ||
+ | |||
+ | |||
+ | :* '''POST''' http://meusitio.es/marcas/{marcas}/perfumes → Para crear un perfume | ||
+ | :* '''PUT''' http://meusitio.es/marca/{marcas}/perfumes/{perfumes} → Para modificar os datos dun perfume concreto | ||
+ | :* '''GET''' http://meusitio.es/marcas/{marcas}/perfumes → Para obter o listado de perfumes dunha marca concreta. | ||
+ | :* '''DELETE''' http://meusitio.es/marcas/{marcas}/perfumes/{id} → Para eliminar un perfume concreto | ||
+ | |||
+ | :* '''GET''' http://meusitio.es/perfumes → Para obter o listado de perfumes. | ||
+ | :* '''GET''' http://meusitio.es/perfumes/{id} → Para obter a información dun perfume concreto | ||
+ | |||
+ | |||
+ | * Imos ter polo tanto tres controladores asociados a estas rutas: | ||
+ | :* MarcasController | ||
+ | :* MarcasPerfumesController | ||
+ | :* PerfumesController | ||
+ | |||
+ | : Os comandos para crear ditos controladores serán: | ||
+ | :* Versión 5.1 ou anteriores: | ||
+ | :::<syntaxhighlight lang="java" line enclose="div" highlight="" > | ||
+ | php artisan make:controller MarcaController | ||
+ | php artisan make:controller PerfumeController | ||
+ | php artisan make:controller MarcaPerfumeController | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | :* Versión 5.2 ou posteriores: | ||
+ | :::<syntaxhighlight lang="java" line enclose="div" highlight="" > | ||
+ | php artisan make:controller MarcaController --resource | ||
+ | php artisan make:controller PerfumeController --resource | ||
+ | php artisan make:controller MarcaPerfumeController --resource | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | |||
+ | * Editamos o arquivo /app/Http/routes.php | ||
+ | ::<syntaxhighlight lang="java" line enclose="div" highlight="" > | ||
+ | Route::resource('marcas','MarcasController', | ||
+ | ['only' => ['store', 'show', 'update', 'destroy','index']]); | ||
+ | |||
+ | Route::resource('marcas.perfumes','MarcasPerfumesController', | ||
+ | ['only' => ['store', 'update', 'index', 'destroy','']]); | ||
+ | |||
+ | Route::resource('perfumes','PerfumesController', | ||
+ | ['only' => ['index', 'show']]); | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | |||
+ | :<u>Nota:</u> Información sobre as rutas [https://ajgallego.gitbooks.io/laravel-5/content/capitulo_5_rest.html neste enlace]. | ||
<br> -- [[Usuario:angelfg|Ángel D. Fernández González]] -- (2017). | <br> -- [[Usuario:angelfg|Ángel D. Fernández González]] -- (2017). |
Revisión del 08:10 17 abr 2017
Sumario
Introdución
- Arquitectura REST.
- Arquitectura REST e regras que debería cumprirse.
- Que é un servizo REST (en español) e regras que debe cumprir.
- Neste manual non aplica ben as regras para que sexa Rest (os código de erro de resposta HTTP).
Servizo REST: Características
- Información obtida deste enlace.
- REST é o acrónimo de Representational State Transfer.
- Para que sexa considerado REST ten que cumprir estas características:
- Baseado nun protocolo de cliente/servidor sen estado (protocolo Http)
- Cacheable
- Escalable
- Con unhas operacións ben definidas no que os recursos estean identificados de forma única por URIs.
- Ao utilizar o protocolo HTTP, xa vimos que non garda o estado polo que deberemos de enviar os datos necesarios para a autenticación en cada petición que fagamos.
- Cada petición que fagamos levará asociada o uso dun verbo que indicará un tipo de acción a realizar:
- GET: Utilízase para acceder a un recurso
- POST: Envía datos para crear un recurso. Os datos non van na URI, se non no corpo da mensaxe.
- PUT: Utilizado para editar un recurso.
- DELETE: Elimina un recurso
- PATCH: Utilízase para modificar parcialmente un recurso. Normalmente faise con PUT.
- Cando fagamos algunha das operacións anteriores deberemos de informar a quen fixo a petición do éxito ou fracaso da operación. Non existe un estándar que nos obrigue a utilizar uns códigos ou outros, pero deberemos de aproveitar' os código HTML para facilitar o 'consumo' do noso servizo REST:
- 200 → OK : Petición recibida e procesada de forma correcta
- 201 → Created : Petición completada. Creouse un novo recurso
- 204 → No Content: Petición procesada correctamente, pero a resposta non ten ningún contido
- 401 → Unauthorized: A información de autenticación non é válida
- 404 → Not found: O recurso non se atopou.
- Cacheable:
- Isto quere dicir que ten que ter a posibilidade de poder 'cachear' os resultados para ter un mellor desempeño.
- As peticións deben indicar se o resultado pode ou non ser cacheado.
- Escalable:
- O servidor encargado de recibir e procesar as respostas debe ser capaz de ser dividido en capas (cada capa se encargará de procesar as peticións de diferentes recursos). Desta forma podemos ter diferentes políticas de seguridade.
- Identificación de recursos mediante URIs:
- Normalmente un servizo REST vai permitir realizar operacións de consulta, actualización, engadir e borrado sobre diferentes elementos de informacións. Es estes elementos denomínanse recursos (por exemplo, engadir un novo libro se xestionamos unha librería, obter o listado de clientes, obter o prezo de todas as pantallas de 14 se xestionamos unha tenda de computadores,...).
- Cando fagamos unha operación sobre un destes recursos, temos que utilizar unha URI que deberá cumprir as seguintes propiedades:
- Deben ser únicas, non pode existir máis dunha URI para identificar o mesmo recurso.
- Deben ser independentes do formato no que queiramos consultar el recurso (a URI debe ser a mesma se devolvemos a información en JSON ou XML, por exemplo)
- Deben manter una xerarquía na ruta do recurso
- No deben indicar accións, polo que non debemos usar verbos á hora de definir unha URI (como viñamos facendo nas aplicacións WEB)
- Por exemplo, se queremos xestionar un recurso 'libros':
- POST http://meusitio.es/libros → Para crear un libro
- GET http://meusitio.es/libros/{id} → Para obter a información dun libro concreto
- PUT http://meusitio.es/libros/{id} → Para modificar os datos dun libro concreto
- DELETE http://meusitio.es/libros/{id} → Para eliminar un libro concreto
- GET http://meusitio.es/libros → Para obter o listado de libros.
- Nota: Normalmente o recurso estará en minúsculas e en plural a no ser que o recurso sexa único (por exemplo a configuración).
- En caso de querer filtrar os recursos faremos uso da URI e enviaremos a información de filtrado usando parámetros da forma: ?param1=valor1¶m2=valor.
- Por exemplo, se queremos obter a lista de libros de informática: http://meusitio.es/libros?tematica=informatica.
- Temos que ter coidado coa xerarquía de recursos e acceder atendendo a dita xerarquía.
- Así se xestiono varias tendas de libros, o acceso a un libro dunha tenda debería ser: http://meusitio.es/tendas/1/libros/5 e non ao revés (http://meusitio.es/libros/5/tendas/1).
- Outras características que deberían cumprir as URI's:
- Utilizar minúsculas y guións ou guións baixos (snake-case) no canto de maiúsculas y minúsculas (CamelCase)
- Non utilizar caracteres que necesiten codificación URL como por exemplo espazos en branco, comillas, etc.
- Non utilizar parámetros de consulta (?tipo=1) en peticións que no sexan de consulta.
- Formato de resposta:
- Normalmente o formato vai ser XML ou JSON.
- Como comentamos anteriormente na URI non debe ir ningunha información sobre o tipo de formato da resposta.
- O tipo de formato da resposta será indicado na cabeceira da petición.
Creación dun servizo web
Base de datos
- Partimos da seguinte base de datos de nome BELLEZA composta polas seguintes táboas:
Táboa MARCAS:
1 CREATE TABLE `BELLEZA`.`MARCAS` ( 2 `id_marca` INT NOT NULL AUTO_INCREMENT, 3 `descripcion` VARCHAR(100) NOT NULL, 4 PRIMARY KEY (`id_marca`));
Táboa PERFUMES:
1 CREATE TABLE `PERFUMES` ( 2 `id_perfume` int(11) NOT NULL AUTO_INCREMENT, 3 `descripcion` varchar(45) COLLATE utf8_spanish2_ci NOT NULL, 4 `prezo` decimal(8,2) NOT NULL, 5 `data_compra` date DEFAULT NULL, 6 `marca_id` int(11) NOT NULL, 7 PRIMARY KEY (`id_perfume`), 8 KEY `fk_PERFUMES_1_idx` (`id_perfume`), 9 KEY `fk_PERFUMES_MARCA_idx` (`marca_id`), 10 CONSTRAINT `fk_PERFUMES_MARCA` FOREIGN KEY (`marca_id`) REFERENCES `MARCAS` (`id_marca`) ON DELETE NO ACTION ON UPDATE CASCADE 11 ) ENGINE=InnoDB AUTO_INCREMENT=16 DEFAULT CHARSET=utf8 COLLATE=utf8_spanish2_ci;
- Algúns datos de exemplo:
1 INSERT INTO `MARCAS` VALUES (1,'CHANNEL'),(2,'ADIDAS'),(3,'ARAMIS');
1 INSERT INTO `PERFUMES` VALUES (1,'Channel 1',46.22,'2017-02-01',1),(2,'Adidas',1.33,NULL,2),(18,'Best Aramis',54.32,'0000-00-00',3);
Nota: Indicar que Laravel como xa comentamos anteriormente permite a creación de táboas usando migracións e enchendo de datos con seeders.
Rutas
- Nota: Lembrar que nun servizo non existen formularios de entrada de datos, polo que as rutas/funcións que dan acceso a ditos formularios sobran.
- Partimos da idea de que un perfume sempre vai pertencer a unha marca e polo tanto non existe se non existe a marca.
- As rutas que imos ter van ser:
- POST http://meusitio.es/marcas → Para crear unha marca
- GET http://meusitio.es/marcas/{marcas} → Para obter a información dunha marca concreta
- PUT http://meusitio.es/marcas/{marcas} → Para modificar os datos dunha marca concreta
- DELETE http://meusitio.es/marcas/{marcas} → Para eliminar unha marca concreta
- GET http://meusitio.es/marcas → Para obter o listado de marcas.
- POST http://meusitio.es/marcas/{marcas}/perfumes → Para crear un perfume
- PUT http://meusitio.es/marca/{marcas}/perfumes/{perfumes} → Para modificar os datos dun perfume concreto
- GET http://meusitio.es/marcas/{marcas}/perfumes → Para obter o listado de perfumes dunha marca concreta.
- DELETE http://meusitio.es/marcas/{marcas}/perfumes/{id} → Para eliminar un perfume concreto
- GET http://meusitio.es/perfumes → Para obter o listado de perfumes.
- GET http://meusitio.es/perfumes/{id} → Para obter a información dun perfume concreto
- Imos ter polo tanto tres controladores asociados a estas rutas:
- MarcasController
- MarcasPerfumesController
- PerfumesController
- Os comandos para crear ditos controladores serán:
- Versión 5.1 ou anteriores:
1 php artisan make:controller MarcaController 2 php artisan make:controller PerfumeController 3 php artisan make:controller MarcaPerfumeController
- Versión 5.2 ou posteriores:
1 php artisan make:controller MarcaController --resource 2 php artisan make:controller PerfumeController --resource 3 php artisan make:controller MarcaPerfumeController --resource
- Editamos o arquivo /app/Http/routes.php
1 Route::resource('marcas','MarcasController', 2 ['only' => ['store', 'show', 'update', 'destroy','index']]); 3 4 Route::resource('marcas.perfumes','MarcasPerfumesController', 5 ['only' => ['store', 'update', 'index', 'destroy','']]); 6 7 Route::resource('perfumes','PerfumesController', 8 ['only' => ['index', 'show']]);
- Nota: Información sobre as rutas neste enlace.
-- Ángel D. Fernández González -- (2017).