Mailinglist Archive: yast-devel (163 mails)

< Previous Next >
Re: [yast-devel] Registration Rest Api
  • From: "J. Daniel Schmidt" <jdsn@xxxxxxx>
  • Date: Mon, 21 Sep 2009 17:17:27 +0200
  • Message-id: <200909211717.27508.jdsn@xxxxxxx>
On Friday 18 September 2009 11:23:17 Klaus Kaempf wrote:

* /registration

As Josef already mentioned, you might want to rename this to
/registration/register. This way the url names the action ('register')
and also matches Rails controller/action pattern for urls.

Yes, it should be compatible with all other URLs. I discussed it with Schubi
last week, and we decided to keep the URL short, as this action is the only
one available.
But I'm fine with renaming it to /registration/register


POST
run registration and return the/a result

post data:

<registration>
<options>
<debug>2</debug>
<nooptional>1</nooptional>
<nohwdata>1</nohwdata>

This negation seems awkward. What's wrong with <optional> and <hwdata> ?
Boolean attributes should also get boolean values (i.e. 'true' instead
of '1').

Sure, only debug mode is non-boolean. Will change it.

But such details (type of attributes) are better left to ActiveResource.


<forcereg>0</forcereg>

This one is boolean, not part of the proxy and a needed switch.


<httpproxy>http://my.proxy</httpproxy>
<httpsproxy>http://my.proxy</httpsproxy>

Hmm, the proxy should belong to the network settings.

Yes this is correct, but for some reason we configured it manually in the
current registration. I'll find out about if we really need this option.


</options>

<arguments>
<argument>
<name>key</name>
<value>val</value>
</argument>

This also looks awkward (should be <key>value</key>) but thats
probably due to ActiveResource.

No, its because the name of the keys are dynamic. There is no fixed list of
possible keys. There can be any of them.


...
</arguments>
<registration>


returns:

<registration>
<status>finished|missinginfo|error</status>
<message>Some text to display</message>

Where does this message come from, how is it translated ?

The registration server can send translated messages if the language is
supported by NCC (see as well "suse_register --locale=XY").

Language setting should be a property of the frontend (webclient), the
service has no idea about the UI language.

The target system has a default language. Thats the language the system gets
registered with. And if a translation exists for this language the
registration server sends answers in this language - these could be displayed.

But if we want to keep the web-client's language setting separate from one on
the target system then we need to have static texts and use exit codes to
identify the actual status.


For the error results, use different class definitions all derived from a
common 'error' class. I guess discussing these classes is easier than
looking at raw xml.

Missing information is not an error, but a valid status within the
registration workflow - see my answer to Josef's eMail.


There is only one action to perform the registration. And all data has to
be send for each request, as it operates in stateless context.
The following action depends on the answer to the request. If there are
arguments missing a following call is needed (together with the
additional arguments).

Is there a state diagram available showing how requests and answers
relate ?

I'll create one.


Ciao,
Daniel

--
J. Daniel Schmidt <jdsn@xxxxxxx> SUSE Linux Products GmbH
Research & Development Maxfeldstr. 5
GF: Markus Rex, HRB 16746 (AG Nürnberg) D-90409 Nürnberg
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups