Mailinglist Archive: yast-devel (39 mails)

< Previous Next >
[yast-devel] Re: discussion points for restful api
  • From: Klaus Kaempf <kkaempf@xxxxxxx>
  • Date: Mon, 27 Apr 2009 14:04:20 +0200
  • Message-id: <20090427120420.GB31183@xxxxxxxxxxxxx>
* Duncan Mac-Vicar P. <dmacvicar@xxxxxxx> [Apr 26. 2009 21:39]:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


* What to Discuss (we should meet and find solutions)

- - Namespaces, domains

This topic is still blur. We want to namespace resources, however it
looks like REST convention only namespace resources if they are nested.

I do not think its a REST convention, but more an ActiveResource and
Rails routing convention. See http://guides.rubyonrails.org/routing.html

The way we use namespaces/domains right now is mostly driven by the
close coupling Rails routing puts between URLs and controllers.


So I have a small feeling that by following to much RESTful practices
we are ignoring others. If we will have /system in the url, that has to
be a resource too.

Not necessarily as REST does not say anything about assembly of URLs.
So having a /system/time resource is fine and does not imply anything
about /system.

More important are the documented URLs as they present entry points into
the resource web. The current proposal for pluggable resources is to
expose only a single URL, namely /yast, and have everything else
reachable via hyperlinks from there.


In other parts we need to also figure good apis.
Absolutely ! This is directly related to the resource model we want to
establish. This is still an open AI.

Right now stuff like patch install is broken, because the resources
are automatically routed (map.resource), so stuff like "install" does
not work.
We have to think how are we going to handle those, at least sit down
and define the few domains we will do for the start. Either we make it
possible for plugged resources to handle custom actions
(patches.put(:install)), making exceptions here and there, or we define
more complicated ones.

I do not think is has to be more complicated if we follow a good
modeling approach. map.resource tries to be 'mostly RESTful', with the
exception of /new and /edit (which we don't need on the server side).
I'd like to follow these conventions.

In this case I do think creating a packageinstallation resource is
too-much.

A packageinstallation resource would be the wrong model. A 'software/installed'
model, representing installed software, would be a better one.
Installing a package would be represented by 'creating a new
software/installed resource instance'.

As usual, the real world puts limitations on the ideal model. Package
installation is transactional and has side effects (i.e. obsoletes)
which isn't really RESTful.


For example, the current automatic resource registration does not allow
nested resources.

Thats rather easy to fix by moving from a static (yaml) resource
description format to a dynamic (.rb files) one.

Can you give a concrete example of where nested resources would help ?


The current navigation of resources is cool, but on the client makes
things complicated for nested resources. You need to know the urls,

The pluggable resource implementation is all about restricting the
exposed (in terms of documentation and stability) URLs to a single one
in order to gain freedom and flexibility of the resource model.


- - Permissions

permissions is a nested resource of users, which is now a separate
resource plugin, therefore I changed the users plugin to manually map
permissions as nested.
However the current permissions is highly dependent on resource names,
and the whole discussion about namespaces, domains, etc makes this very
inconsistent. We need to design this so we can enable it.

The inconsistency should go away as we separate the resource name from
its implementation in Rails.

Being RESTful means to report insufficient permissions with proper
http status codes if an unauthorized access is attempted.

The current use of permissions couples two modeling aspects. That of a
resource and that of access rights to manage the resource. We might
want to keep it that way and document it as an exception to the
RESTful convention.

Or we model a permissions resource, relating users to resources. This
would give us more flexibility, e.g. granting rights by creating a
permission resource or revoking rights by deleting a permissions
resource.

Klaus
---
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N├╝rnberg)

--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
References