@@ -102,7 +102,7 @@ efforts sur l'utilisation de [JSONP](http://en.wikipedia.org/wiki/JSONP) ou [COR
102102Certains problèmes de conception sont récurrents dans les APIs REST, et
103103les opinions sont souvent bien trop tranchées.
104104
105- Le versioning revient souvent dans les préoccupations:
105+ ### Le versioning revient souvent dans les préoccupations
106106
107107* pour identifier différentes versions d'une API, l'utilisation d'un
108108 préfixe est [ souvent
@@ -113,7 +113,22 @@ recommandé](http://stackoverflow.com/questions/389169/best-practices-for-api-ve
113113 ressource particulière), l'utilisation des Etags (pour le cache) et/ou
114114d'un numéro de version dans votre ressource sont suffisants
115115
116- En cas de doute, il est souvent utile de se référer à une API REST très
116+ ### Documentation et "découvrabilité"
117+
118+ La documentation est un aspect essentiel d'une API REST. Certains
119+ prennent le parti d'automatiser et d'outiller un maximum la
120+ documentation: par exemple, avec [ jax-doclets] ( http://www.lunatech-labs.com/open-source/jax-doclets ) .
121+
122+ Pour aller plus loin, les APIs peuvent apporter une "découvrabilité":
123+ permettre au protocole HTTP de documenter l'utilisation de l'API. En
124+ clair, donner au client REST des indications sur les actions possibles
125+ via les headers réponse HTTP. Martin Fowler l'explique bien dans un
126+ article sur le [ Richardson Maturity
127+ Model] ( http://martinfowler.com/articles/richardsonMaturityModel.html ) .
128+
129+ ### En cas de doute...
130+
131+ Il est souvent utile de se référer à une API REST très
117132utilisée et reconnue: l'[ API github] ( http://developer.github.com/ ) est considérée comme une des
118133meilleures à ce jour.
119134
@@ -125,19 +140,16 @@ Aussi, je vous recommande la lecture des articles de Steve Klabnik:
125140 HTTP"] ( http://blog.steveklabnik.com/2011/08/07/some-people-understand-rest-and-http.html )
126141
127142
128- ## Bibliographie
129-
130- Quelques ressources utiles:
143+ ## Ressources utiles
131144
132- * documenter son API REST avec
133- [ jax-doclets] ( http://www.lunatech-labs.com/open-source/jax-doclets )
134- * tester son API REST depuis son navigateur avec une [ extension Chrome] ( https://chrome.google.com/webstore/detail/cokgbflfommojglbmbpenpphppikmonn ) ou
145+ * Tester son API REST depuis son navigateur avec une [ extension Chrome] ( https://chrome.google.com/webstore/detail/cokgbflfommojglbmbpenpphppikmonn ) ou
135146 avec CURL!
136147* Google a beaucoup travaillé sur les aspects RDF/atomPUB avec
137148 [ Gdata] ( http://code.google.com/intl/fr-FR/apis/gdata/ )
138- * le projet Jersey a de [ nombreux exemples d'APIs
149+ * Le projet Jersey a de [ nombreux exemples d'APIs
139150 REST] ( http://download.java.net/maven/2/com/sun/jersey/samples/jersey-samples/ )
140- sur des aspects particuliers
151+ sur des aspects particuliers, dont
152+ [ Hypermedia] ( http://download.java.net/maven/2/com/sun/jersey/experimental/hypermedia-action/hypermedia-action-sample/ )
141153* Mettre en place un [ "rate
142154 limiting"] ( http://stackoverflow.com/questions/667508/whats-a-good-rate-limiting-algorithm )
143155sur son API peut aussi bénéficier d'un cache distribué (memcached,
0 commit comments