2011-03-13 21 views
6

Estoy en el proceso de crear una API RESTful. He leídoDesign RESTful URI

http://microformats.org/wiki/rest/urls

pero este sitio no me da suficiente "buena" práctica en el diseño de mi API. Específicamente escribiré una API (solo los métodos GET hasta ahora) que proporcionarán funciones para convertir coordenadas geográficas.

Ejemplo: A geohash es una representación única de valor de una coordenada, así /convert/geohash/u09tvkx0.json?outputformat=latlong

tiene sentido. Por otro lado, /convert/latlong.xml?lat=65 & long = 13 & outputformat = UTC requiere dos valores de entrada.

Ver mi "pregunta"? ¿Qué hace una buena API que requiere más de un parámetro de entrada?

(tratado de "identificar" buenas prácticas por "analizar" gorjeo & FF pero no)

Respuesta

4

En términos de ser considerado un "técnicamente" correcto REST URI, no hay diferencia entre el uso de parámetros de cadena de consulta o no . En RFC 3986, se indica:

El componente de consulta contiene datos no jerárquica que, junto con los datos en el componente de trazado (Sección 3.3), sirve para identificar un recurso

Es por eso que eres teniendo dificultades para encontrar una "mejor práctica" definitiva. Una vez dicho esto, muchas API REST incrustan múltiples parámetros en el URI sin utilizar cadenas de consulta. Por ejemplo, para identificar el modelo de automóvil y, verá sitios web con URI como este: cars.com/honda/civic. En ese caso es muy obvio la relación entre los 2 y así tener todo en el URI es "pirateable". También es mucho más fácil seguir un enfoque de cadena sin consulta cuando solo tiene un parámetro que identifica de manera única el recurso; pero si es algo así como una consulta de búsqueda, entonces probablemente lo mantendría en la cadena de consulta. Este SO question también tiene una discusión interesante sobre los diferentes enfoques.

En su ejemplo anterior, me quedaría con los parámetros de cadena de consulta. Aunque REST generalmente tiene URL más intuitivas, de eso no se trata realmente REST. REST es más sobre hypermedia y HATEOAS.

+0

Gracias por esta explicación! Llenaba el vacío conceptual que tenía con los "principios de diseño" de REST. No estaba al tanto de HATEOAS pero me gusta la actitud. – JohnDoe

0

Hay pocas mejores prácticas REST a seguir en el diseño de una API REST

  1. Resumen vs hormigón
  2. Operaciones CRUD
  3. Manejo de errores
  4. API de versiones
  5. Filtrado
  6. Seguridad
  7. Analytics
  8. Documentación
  9. estabilidad y consistencia
  10. Estructura URL

Read More