Diferencia entre revisiones de «PHP Servizos Web»

De MediaWiki
Ir a la navegación Ir a la búsqueda
(u)
Línea 1: Línea 1:
 +
 +
== Introdución ==
  
 
* [http://blog.architexa.com/2010/11/rest-architecture-simplified/ Arquitectura REST].
 
* [http://blog.architexa.com/2010/11/rest-architecture-simplified/ Arquitectura REST].
Línea 14: Línea 16:
  
 
* [http://www.apañados.es/tenemos-que-apanar/internet-tutoriales-y-trucos/146-40-apis-utiles-disenadores-desarrolladores-web.html Exemplos de APIs en Internet]
 
* [http://www.apañados.es/tenemos-que-apanar/internet-tutoriales-y-trucos/146-40-apis-utiles-disenadores-desarrolladores-web.html Exemplos de APIs en Internet]
 +
 +
 +
== Servizo REST ==
 +
: Información obtida [http://www.i2factory.com/es/integracion/qu%C3%A9-es-un-servicio-restful deste enlace].
 +
 +
* REST é o acrónimo de <b>Re</b>presentational <b>S</b>tate <b>T</b>ransfer.
 +
 +
 +
* 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 [https://es.wikipedia.org/wiki/Identificador_de_recursos_uniforme 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 <u>non debemos usar verbos á hora de definir unha URI</u> (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.
 +
 +
 +
:<u>Nota:</u> 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&param2=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.
 +
 +
 +
 +
  
  
 
<br> -- [[Usuario:angelfg|Ángel D. Fernández González]] -- (2016).
 
<br> -- [[Usuario:angelfg|Ángel D. Fernández González]] -- (2016).

Revisión del 06:36 17 abr 2017

Introdución

  • Neste manual non aplica ben as regras para que sexa Rest (os código de erro de resposta HTTP).




Servizo REST

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':


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&param2=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.





-- Ángel D. Fernández González -- (2016).

Obtenido de «https://wiki.cifprodolfoucha.es/index.php?title=PHP_Servizos_Web&oldid=3758»