ıllı Internet y Tecnologías de la Información (2018)

internet, Hosting, dominios, seo, antivirus, banco de imágenes, páginas web, tiendas online

[Enciclopedia Online Gratuita] Diccionario de Internet y Tecnologías de la Información y la Comunicación (TIC):

ıllı Transferencia de Estado Representacional wiki: info, historia y vídeos


La información contenida en esta web debe ser considerada como información general, de carácter formativo, educativo o divulgativo, y no puede ser utilizada o interpretada como consejo o diagnótico médico, psicológico o de ningún otro tipo. Es posible que algunos datos mostrados no esten actualizados. Por ello, en caso de duda lo recomentable es consultar a un experto cualificado.


 


 

videos internet

salud  Transferencia de Estado Representacional 


Roy Fielding charlando a lo largo de OSCON 2008

Si bien el término REST se refería originalmente a un conjunto de principios de arquitectura —descritos más abajo—, hoy día se utiliza en el sentido más extenso para describir cualquier interfaz entre sistemas que utilice de forma directa HTTP para conseguir datos o bien señalar la ejecución de operaciones sobre los datos, en cualquier formato (XML, JSON, etcétera sin las abstracciones auxiliares de los protocolos basados en patrones de intercambio de mensajes, como por poner un ejemplo SOAP. Es posible diseñar sistemas de servicios web conforme con el estilo arquitectural REST de Fielding y asimismo es posible diseñar interfaces XMLHTTP conforme con el estilo de llamada a procedimiento recóndito (RPC), mas sin emplear SOAP. Estos 2 usos diferentes del término REST ocasionan cierta confusión en las discusiones técnicas, si bien RPC no es un caso de REST.


REST asevera que la página web ha gozado de escalabilidad a resultas de una serie de diseños esenciales clave:



  • Un protocolo cliente/servidor sin estado: cada mensaje HTTP contiene toda la información precisa para entender la solicitud. Como resultado, ni el usuario ni el servidor precisan rememorar ningún estado de las comunicaciones entre mensajes. No obstante, en la práctica, muchas aplicaciones basadas en HTTP usan cookies y otros mecanismos para sostener el estado de la sesión (ciertas de estas prácticas, como la reescritura de URLs, no son toleradas por REST)


  • Un conjunto de operaciones bien definidas que se aplican a todos y cada uno de los recursos de información: HTTP en sí define un conjunto pequeño de operaciones, las más esenciales son POST, GET, PUT y DELETE. Habitualmente estas operaciones se comparan a las operaciones CRUD en bases de datos (CLAB en castellano: crear,leer,actualizar,borrar) que se requieren para la persistencia de datos, si bien POST no encaja precisamente en este esquema.


  • Una sintaxis universal para identificar los recursos. En un sistema REST, cada recurso es direccionable solamente mediante su URI.


  • El empleo de hipermedios, tanto para la información de la aplicación para las transiciones de estado de la aplicación: la representación de este estado en un sistema REST son típicamente HTML o bien XML. A resultas de esto, es posible navegar de un recurso REST a otros muchos, sencillamente siguiendo links sin requerir el empleo de registros o bien otra infraestructura auxiliar.

Un término esencial en REST es la existencia de recursos (elementos de información), que pueden ser accedidos usando un identificador global (un Identificador Uniforme de Recurso). Para manipular estos recursos, los componentes de la red (clientes del servicio y servidores) se comunican por medio de una interfaz estándar (HTTP) y también intercambian representaciones de estos recursos (los archivos que se descargan y se mandan) - es cuestión de discute, sin embargo, si la distinción entre recursos y sus representaciones es demasiado platónica para su empleo práctico en internet, si bien es popular en la comunidad RDF.


La solicitud puede ser trasmitida por cualquier número de conectores (por servirnos de un ejemplo clientes del servicio, servidores, cachés, túneles, etcétera) mas cada uno de ellos lo hace sin "ver más allí" de su solicitud (lo que es conocido como stateless (sin estado), otra limitación de REST, que es un principio común con otras muchas unas partes de la arquitectura de redes y de la información). De este modo, una aplicación puede interaccionar con un recurso conociendo el identificador del recurso y la acción requerida, no necesitando conocer si existen cachés, proxys, cortafuegos, túneles o bien cualquier otra cosa entre ella y el servidor que guarda la información. La aplicación, no obstante, debe entender el formato de la información devuelta (la representación), que es por norma general un documento HTML o bien XML, si bien asimismo puede ser una imagen o bien cualquier otro contenido.


Una aplicación web REST requiere un enfoque de diseño diferente a una aplicación basada en RPC (llamada de procedimiento recóndito). En RPC, se pone el énfasis en la diversidad de operaciones del protocolo, o bien verbos; por servirnos de un ejemplo una aplicación RPC podría delimitar operaciones como:





  • getUser()
  • addUser()
  • removeUser()
  • updateUser()
  • getLocation()
  • addLocation()
  • removeLocation()
  • updateLocation()
  • listUsers()
  • listLocations()
  • findLocation()
  • findUser()

En REST, al revés, el énfasis se pone en los recursos, o bien sustantivos; singularmente en los nombres que se le asigna a cada género de recurso. Por servirnos de un ejemplo, una aplicación REST podría delimitar ciertos géneros de recursos asignándoles estos nombres:



  • Usuario
  • Localización

Cada recurso tendría su identificador, como http://www.example.org/locations/us/ny/new_york_city. Los clientes del servicio trabajarían con estos recursos por medio de las operaciones estándar de HTTP, como GET para descargar una copia del recurso. Obsérvese de qué manera cada objeto tiene su URL y puede ser sencillamente cacheado, copiado y guardado como marcador. POST se emplea por norma general para acciones con efectos laterales, como mandar una orden de adquiere o bien agregar determinados datos a una compilación.


Por ejemplo, el registro para un usuario podría tener el próximo aspecto:

<usuario> <nombre>María Juana</nombre> <sexo>mujer</sexo> <localización href="http://www.example.org/locations/us/ny/new_york_city">Nueva York, NY, US</localización></usuario>

Para actualizar la ubicación del usuario, un cliente del servicio REST podría primero descargar el registro XML precedente utilizando GET. El usuario después alteraría el archivo para mudar la ubicación y lo subiría al servidor usando HTTP PUT.


Nótese, no obstante, que los verbos HTTP (POST, GET, PUT, DELETE) no dan ningún mecanismo estándar para descubrir recursos -- no existe ninguna operación LIST o bien FIND en HTTP, que se corresponderían con las operaciones list*() y find*() en el ejemplo RPC.En su sitio, las aplicaciones basadas en datos REST resuelven el inconveniente tratando una compilación de resultados de la búsqueda como otro género de recurso, lo que requiere que los diseñadores de la aplicación conozcan URLs auxiliares para enseñar o bien buscar cada género de recurso.


Por ejemplo, una solicitud GET HTTP sobre la URL http://www.example.org/locations/us/ny/ podría devolver un link a una lista de archivos en XML con todas y cada una de las localizaciones posibles en la ciudad de Nueva York, al tiempo que una solicitud GET a la URL http://www.example.org/users?surname=Michaels podría devolver una lista de links a todos y cada uno de los usuarios con el apellido "Michaels".


REST da ciertas indicaciones sobre de qué forma efectuar esta clase de acciones como una parte de su limitación "hipermedia como el medio de estado de la aplicación", lo que sugiere el empleo de un lenguaje de formularios (como un formulario HTML) para concretar consultas parametrizadas.


La iniciativa OpenSearch de A9.com procura normalizar las buscas utilizando REST estableciendo especificaciones para descubrir recursos y un formato genérico para usar con sistemas basados en REST, incluyendo el RDF, XTM, Atom, RSS (en sus múltiples formas) y XML con XLink para administrar los links.


Dado que la definición de REST es amplísima, es posible aseverar que hay un enorme número de aplicaciones REST en internet (prácticamente cualquier cosa alcanzable a través de una solicitud HTTP GET). De forma más restrictiva, en contraposición a los servicios web y el RPC, REST se puede hallar en diferentes áreas de la web:


Probablemente existan otras muchas implementaciones afines.


En cualquier caso debe tenerse en cuenta que muchas de las implementaciones descritas arriba, no son completamente RESTful, esto es, no respetan todas y cada una de las limitaciones que impone la arquitectura REST. No obstante todas y cada una están inspiradas en REST y respetan los aspectos más significativos y restrictivos de su arquitectura, particularmente la limitación de "interfaz uniforme". Estos servicios han sido llamados "Accidentariamente RESTful".


  ELIGE TU TEMA DE INTERÉS: 


autoayuda.es   Internet y Tecnologias 





Está aquí: Inicio > [ INTERNET ] > ıllı Transferencia de Estado Representacional wiki: info, historia y vídeos

Las cookies nos permiten ofrecer nuestros servicios. Al utilizar nuestros servicios, aceptas el uso que hacemos de las cookies. Ver políticas