Servicios web tranquilos

Question

¿Qué debe evitar al configurar una interfaz Restful para asegurarse de que no la haya convertido en una RPC?

Answer 1

Do:

• diseñar la aplicación para ser hypertext-driven (hipermedia como el motor de la Solicitud de Estado - HATEOAS).
• Dedique la mayor parte de su tiempo y esfuerzo a identificar recursos y crear tipos de medios para representarlos.
• Considere todo el URI como su identificador de recursos, y suponga que cambiará en el futuro.
• Proporcione todas las opciones para continuar más a través de su aplicación como enlaces en su representación.
• Piense en su aplicación como un sitio web que los clientes "rastrearán" o "explorarán".
• Intenta escribir un cliente para tu API y busca dónde se produce el acoplamiento.

no:

• publicar plantillas de URI en la documentación de la API. Si debe tener plantillas para parámetros de consulta, por ejemplo, asegúrese de que sean parte de su definición de tipo de medio.
• Piense en su aplicación como una colección de URI en los que actúan cuatro verbos.
• Sirva tipos de mime como "application/xml" o "application/json" a los clientes.

Para utilizar una analogía, su API debería funcionar más como un GPS para sus clientes y menos como un mapa. Solo proporcionará a los clientes el nombre de una calle cercana.Pero a partir de ese momento, solo pueden hacer lo que su aplicación dice que pueden hacer en cualquier punto dado.

El propósito de este estilo es minimizar el acoplamiento entre su aplicación y sus clientes. Todo el acoplamiento debe ocurrir en su definición de tipo de medio. Esto simplifica la evolución de la API y proporciona un buen mecanismo para el control de versiones. También hace que las preguntas sobre cuestiones como la paginación desaparezcan.

La mayoría de las API "RESTful" no siguen este patrón. Para uno que lo haga, vea el Sun Cloud API y su backstory.

Answer 2

Es una pregunta amplia pero voy a intentarlo. Por un lado, solo use los verbos HTTP como se pretendía. No publique en una URL con un argumento de URL que básicamente anula el POST y lo convierte en un GET o DELETE. Así es como funciona SOAP (todo es un POST).

Answer 3

Aproveche el protocolo subyacente cuando sea posible. En lugar de tener verbos en su carga útil, intente utilizar (por ejemplo) los métodos HTTP GET, POST, PUT, DELETE. Su URI debe describir un recurso pero no qué hacer con él.

Answer 4

Algunas de las cosas que desea evitar son:

• Haciendo caso omiso de almacenamiento en caché
• Tunneling todo a través de (o, alternativamente POST)
• Haciendo caso omiso de los tipos MIME

Hay un buen artículo aquí que habla sobre algunos de los patrones de REST:

http://www.infoq.com/articles/rest-anti-patterns

Answer 5

Este artículo detalla algunas decisiones de diseño que diferencian RPC desde el reposo:

http://www.pluralsight.com/community/blogs/tewald/archive/2007/04/28/47067.aspx

@ S. Lott: gracias, sinceramente pensé que había publicado que a medida que la respuesta no es un comentario. Estoy perdiendo mis canicas.