Defect #7661

xml attributes names should be consistent throughout ALL REST API

Added by Alex Last almost 11 years ago. Updated almost 11 years ago.

Status:NewStart date:2011-02-19
Priority:NormalDue date:
Assignee:Jean-Philippe Lang% Done:

0%

Category:REST API
Target version:-
Resolution: Affected version:1.1.1

Description

"User" returned by Redmine's REST API in response to getUser() command, has separate login, firstname, lastname attributes in the XML.
at the same time, XML returned on getIssues() request has "assignee" and "author" elements with "name" attribute in them, which includes "firstname_space_lastname". This inconsistency in the xml element names makes it harder to use automated parsing (say, with Simple XML or Google GSon libraries), where I could just add "attribute name" tags in Java beans themselves and let those libraries do the transformation for me. instead of that, I have to maintain several XML mapping files (Java beans <==> XML) for different REST XML responses.

proposal: use the same XML attribute names throughout all REST API.

Some lines from my current Castor XML mapping file for Redmine issues:

    <class name="org.redmine.ta.beans.Issue">
        <map-to xml="issue"/>

        <field name="id" type="integer">
            <bind-xml name="id" node="element" />
        </field>
        <field name="assignee" type="org.redmine.ta.beans.User">
            <bind-xml name="assigned_to" />
        </field>
        <field name="author" type="org.redmine.ta.beans.User">
            <bind-xml name="author" />
        </field>

    <class name="org.redmine.ta.beans.User">
        <field name="id" type="integer">
            <bind-xml name="id" node="attribute" />
        </field>
        <field name="fullName" type="string">
            <bind-xml name="name" node="attribute" />
        </field>
    </class>

and now file to parse Users:

<mapping>
    <description>Redmine XML -> Java API binding. see
        https://code.google.com/p/redmine-java-api</description>

    <class name="org.redmine.ta.beans.User">
        <map-to xml="user" />

        <field name="id" type="integer">
            <bind-xml name="id" node="element" />
        </field>
        <field name="login" type="string">
            <bind-xml name="login" node="element" />
        </field>
        <!--  note: "pasword" field is only used when creating a user using the API -->
        <field name="password" type="string">
            <bind-xml name="password" node="element" />
        </field>
        <field name="firstName" type="string">
            <bind-xml name="firstname" node="element" />
        </field>
        <field name="lastName" type="string">
            <bind-xml name="lastname" node="element" />
        </field>
        <field name="mail" type="string">
            <bind-xml name="mail" node="element" />
        </field>
        <field name="createdOn" type="string" 
            handler="org.redmine.ta.internal.RedmineLongDateHandler">
            <bind-xml name="created_on" node="element" />
        </field>
        <field name="lastLoginOn" type="string" 
            handler="org.redmine.ta.internal.RedmineLongDateHandler">
            <bind-xml name="last_login_on" node="element" />
        </field>
    </class>
</mapping>

History

#1 Updated by Jean-Philippe Lang almost 11 years ago

I think that user's name (aka fullName) can be usefull when displaying a list of issue.
Can't we just add this read-only property to the users API?

#2 Updated by Alex Last almost 11 years ago

full name is definitely useful, but my suggestion is to use the same attribute names in all REST API responses.
e.g. instead of "fullname" or ambiguous "name" we could have "first_name", "last_name", "login" in both "issues.xml" and "users.xml" responses. I think the GUI layer should be able to glue "first_name" and "last_name" together itself.

Side note: I don't see a need in separate first and last name fields at all, btw. when I create a user in Redmine or any other system, I'd be fine with providing just "name" and I don't care which part of it is the 1st name and which one - the family one. but that's just my preference :).

Also available in: Atom PDF