2010-02-12 3 views
2

Nous avons utilisé Jersey pour notre webservice et c'était super et simple. Est-il possible d'ajouter un petit commentaire de description dans une définition de méthode (en utilisant peut-être une annotation comme @description):Ajouter commentaire de méthode avec Jersey

@GET 
@Path("/schema/classes/") 
@Produces({ APPLICATION_RDF, TEXT_N3, APPLICATION_JSON }) 
@Description("Lists all ontology classes") 
public Response getClasses() throws JobOntoException { 
    ... 
} 

Et dans le WADL qui donnerait quelque chose comme:

<application> 
<doc jersey:generatedBy="Jersey: 1.1.5 01/20/2010 03:55 PM"/> 
    <resources base="http://localhost:9998/"> 
    <resource path="/jobonto"> 
    <resource path="/schema/classes/"> 
    <method name="GET" id="getClasses"> 
     **<description>"Lists all ontology classes"</description>** 
     <response> 
     <representation mediaType="application/rdf+xml"/> 
     <representation mediaType="text/rdf+n3"/> 
     <representation mediaType="application/json"/> 
     </response> 
    </method> 
    </resource> 
    ... 

Merci, Renaud

Répondre

2

Vous devriez essayer l'extension de la WadlGeneratorConfig.

+0

Les deux liens sont brisés; Je ne suis pas sûr mais je suppose que c'est la nouvelle adresse: https://github.com/jersey/jersey-1.x/tree/master/samples/extended-wadl-webapp – lapo

0

Voici une idée encore meilleure. Placez la description dans la représentation que vous utilisez pour lier à cette ressource.

Quel type de média utilisez-vous pour la représentation à la racine de votre service? Xhtml peut être très utile pour cela car il est facile à analyser, a un support existant pour les liens et rend bien dans un navigateur.

+0

Nous utilisons JSON, et rdf ou n3. En fait, je suis plus intéressé par la description de la méthode de service que par la manière dont les représentations sont structurées. – Renaud

0

Renaud,

vous utilisez la WADL pour fournir une description de service au développeur du client?

Si tel est le cas, veuillez noter que ce n'est pas RESTful car cela viole la contrainte hypermédia. WADL exprime des informations sur lesquelles un développeur client ne doit pas s'appuyer. WADL contient essentiellement des informations sur les transitions disponibles et la contrainte hypermédia requiert que ces informations soient découvertes lors de l'exécution, mais ne soient pas connues au moment du design. Ainsi, utiliser WADL ad runtime dans le sens d'un formulaire est très bien [1] car vous pouvez changer le WADL sans casser aucun client.

[1] Bien que le style est discutable - personnellement, je préfère concevoir les types de médias spécifiques domaine

Jan

+0

Merci Jan, Oui, nous aimerions utiliser le WADL (qui est généré à la volée par Jersey) comme une sorte de mini-spécification/description pour le développement du client. Je comprends qu'en théorie WADL ne sont pas censés être utilisés comme ça. Mais pour notre projet, ce sera une documentation suffisante pour les clients/consommateurs. Ceux-ci ne découvriront pas le service dynamiquement/à l'exécution, et les méthodes de service ne changeront probablement pas très souvent. – Renaud

+0

Oui, vous pouvez bénéficier de HTTP en termes de simplicité et de visibilité. Je viens juste de commencer à pointer les gens vers ce qui est et ce qui n'est pas RESTful. Donc désolé vous étiez un peu dans la ligne de feu :-) Jan –

Questions connexes