Pregunta

Estoy trabajando en una aplicación basada en web que utiliza un JSON a través de HTTP API basada en la comunicación entre el servidor y el cliente. El objetivo es que varios clientes se pueden desarrollar con diferentes objetivos (cliente Web en línea, cliente de escritorio fuera de línea o de terceros) creado utilizando los mismos datos en línea para ser compartido a través de este servicio web.

En este momento la comunicación entre el cliente y el servidor se envía a través de POST sólo a través de un sistema que funciona bien. He leído un poco de información sobre el descanso y estar tranquilo, con el uso de HTTP PUT, GET, POST y DELETE. Pude separar mi API en estas diferentes categorías, pero significa más código y algunos cambios en el API.

Mi pregunta es: ¿Cuán importante es para una API basada en REST HTTP ser? Es una recomendación, una opción o una necesidad cercano?

Gracias de antemano.

¿Fue útil?

Solución

Como acérrimos RESTafarian yo diría que el uso de HTTP (protocolo REST en cuestión) en toda su extensión. ¿Por qué? Bueno, te voy a mostrar dos fragmentos de un intercambio de correo electrónico que tuve ayer con un buen amigo mío que es serio inteligente (y que solía ser un profesor de TI, todavía conferencias, todavía se inicia el culo donde quiera que vaya);

  

Ayer pasé un importante   hito para mi mappodrhom
  aplicación: ahora puedo lanzar   de larga duración cálculos fondo
  trabajador en una piscina. Cuando terminan,   los trabajadores después de vuelta a sus resultados   directamente en los recursos REST.   Que desencadena más antecedentes   procesamiento, todo controlado por una   gráfica de dependencia.

     

Y el aspecto interesante es que   este backgrounding REST es
  En realidad independiente de mi   aplicación particular. Pero estoy
  Actualmente demasiado cansado para completamente   captar las consecuencias: -)

Las consecuencias de que se trata son enormes (que es un marco de descanso con un montón de pequeñas pilas y eventos y servicios y aplicaciones, todas con su propio detectable URI, todos con la misma interfaz unificada), y en términos de extensibilidad y escalabilidad es simplemente incomparable en su simplicidad. Si la aplicación es una pequeña cosa mala muerte que nunca va a viajar o lugares cumplir con chicas calientes, sí tal vez no lo necesite. Pero entonces, he dicho lo mismo, y, de repente encontré a mí mismo en un tren a París con una chica linda que es un espía secreto por los rusos, y así, una cosa llevó a la otra ...

Aquí está mi respuesta, con algunos de mis propias experiencias;

  

Creo que esto suena (perdón por mi francés)   f *** ing impresionante! Estoy experimentando   cosas similares con mi propio material de descanso,   donde debido a que la capa media es tan   delgada y transparente, sólo puede   extender las cosas como yo las necesito   sin preocuparse demasiado acerca de la   infraestructura. Es una libertad tal,   Una cosa divertida tales kick-culo que mi   cerebro es aproximadamente explotar, y una   curiosidad preocupante de por qué más no son   haciéndolo?

En resumen, RESTO haciendo sólo la mitad de camino es igual que en realidad no hacerlo en absoluto. No eres más que desplazar el material a través de una tubería diferente, perdiendo una API simplificada en una máquina de estados, semantics- e implementación de desacoplamiento en el centro, en colaboración con los principios que construye la red (y por lo tanto yo diría que' he conseguido las ideas en vez comprobados detrás de usted), la interfaz unificada, y que tienen URIs como parte de su modelado.

Sé que es popular decir que usted puede escoger y elegir, de que todo son sólo opciones. No es. RESTO sólo tiene sentido utilizando plenamente, pero en cuanto a convencer a estirar realidad su cerebro un poco más allá y hacer algo inteligente, lo único que se atreve a cortar a través de la FUD (que es todo acerca de RPC, sólo el GET y POST es necesario, usted no necesita todo, lo que equivale a JSON, SOAP y otra calaña, etc.), y ser más inteligentes acerca de cómo hacer que las aplicaciones. Sí, me atrevo a todos!

Otros consejos

A menos que usted va a tomar ventaja de hipermedia, entonces no me moleste en tratar de ajustarse a las limitaciones REST. Hipermedia es la pieza del rompecabezas que hace que el sistema mayor que la suma de sus partes.

Usted es libre de escoger y elegir cuál de las limitaciones REST que desea respetar en su arquitectura, simplemente cuenta que para ser capaz de llamar al resultado final REST, la única restricción opcional es "código-descarga".

Es una opción entre varios para exponer una aplicación web como un servicio web con un API bien definido. Otras opciones incluyen:

  1. No API - La aplicación no tiene ninguna forma real de ser utilizado como un componente en otros sistemas distribuidos
  2. de SOAP - Un formato XML para la definición de las llamadas remotas de API
  3. JSON - Un formato compacto para el intercambio de información que se puede construir en crear un formato de API personalizado (o se utiliza para construir un sistema REST si quería)
  4. Muchas otras formas de llamadas a procedimiento remoto y medios de intercambio de información.

RESTO tiene un bonito ideales detrás de él, pero eso no significa que tenga que proporcionar una API REST para su aplicación. Si la ganancia no vale la pena el esfuerzo extra, no se moleste.

Es una recomendación. Me alegro de que no entró en la forma en REST que necesita para entrar en ya que hay algo que se llama Hi-Lo-Descanso y REST. Se puede obtener más información de google. Algunos veteranos de la industria que conozco no les importa mucho acerca de esto, pero yo no encontrar permanecer lo más cerca posible de HTML y HTTP le ayudará en el largo plazo y simplifica muchas cosas.

Yo diría que es un bueno tener, pero no es una obligación. En mi experiencia la adición de esta arquitectura aumenta el alcance y la complejidad del proyecto, pero añade un grado de elegancia al conjunto. Yo diría que si usted tiene el tiempo y el presupuesto en el proyecto, ir a por ello, si no no se preocupe por ello.

Uno (de las muchas) cosas a tener en cuenta con el API del servicio es la facilidad con la que pueden ser consumidos por el usuario final. RESTO está ganando una presencia muy fuerte de herramientas.

Con mucho, el grupo más grande dev por ahí es el grupo dev .NET, y con ADO.NET para servicios (Astoria) que consumen RESTO mediante LINQ es muy simple y muy elegante.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top