Note that there are some explanatory texts on larger screens.

plurals
  1. POPython object hierarchy, and REST resources?
    primarykey
    data
    text
    <p>I am currently running into an "architectural" problem in my Python app (using Twisted) that uses a REST api, and I am looking for feedback.</p> <p>Warning ! long post ahead!</p> <p>Lets assume the following Object hiearchy:</p> <pre><code>class Device(object): def __init__(): self._driver=Driver() self._status=Status() self._tasks=TaskManager() def __getattr__(self, attr_name): if hasattr(self._tasks, attr_name): return getattr(self._tasks, attr_name) else: raise AttributeError(attr_name) class Driver(object): def __init__(self): self._status=DriverStatus() def connect(self): """some code here""" def disconnect(self): """some code here""" class DriverStatus(object): def __init__(self): self._isConnected=False self._isPluggedIn=False </code></pre> <p>I also have a rather deep object hiearchy (the above elements are only a sub part of it) So, right now this gives me following resources, in the rest api (i know, rest isn't about url hierarchy, but media types, but this is for simplicity's sake):</p> <p>/rest/environments</p> <p>/rest/environments/{id}</p> <p>/rest/environments/{id}/devices/</p> <p>/rest/environments/{id}/devices/{deviceId}</p> <p>/rest/environments/{id}/devices/{deviceId}/driver</p> <p>/rest/environments/{id}/devices/{deviceId}/driver/driverstatus</p> <p>I switched a few months back from a "dirty" soap type Api to REST, but I am becoming unsure about how to handle what seems like added complexity:</p> <ol> <li><p><em>Proliferation of REST resources/media types</em> : for example instead of having just a <strong>Device</strong> resource I now have all these resources:</p> <ul> <li>Device</li> <li>DeviceStatus</li> <li>Driver</li> <li>DriverStatus</li> </ul> <p>While these all make sense from a Resfull point of view, is it normal to have <strong>a lot</strong> of sub resources that each map to a separate python class ?</p></li> <li><p><em>Mapping a method rich application core to a Rest-Full api</em> : in Rest <strong>resources should be nouns, not verbs</strong> : are there good rules /tips to inteligently define a set of resources from a set of methods ? (The most comprehensive example I found so far seems to be <a href="http://bitworking.org/news/201/RESTify-DayTrader" rel="nofollow">this article</a>)</p></li> <li><p><em>Api logic influencing application structure</em>: should an application's API logic at least partially guide some of its internal logic, or is it good practice to apply separation of concerns ? Ie , should I have an intermediate layer of "resource" objects that have the job of communicating with the application core , but that <strong>do not</strong> map one to one to the core's classes ?</p></li> <li><p>How would one correctly handle the following in a rest-full way : I need to be able to display a list of available driver types (ie class names, not Driver instance) in the client : would this mean creating yet another resource like "DriverTypes" ?</p></li> </ol> <p>These are rather long winded questions, so thanks for your patience, and any pointers, feedback and criticism is more than welcome !</p> <hr> <p>To S.Lott:</p> <ul> <li><p>By "too fragmented resources" what i meant was, lots of different sub resources that basically still apply to the same server side entity</p></li> <li><p>For The "connection" : So that would be a modified version of the "DriverStatus" resource then ? I consider the connection to be always existing, hence the use of "PUT" , but would that be bad thing considering "PUT" should be idempotent ? </p></li> <li><p>You are right about "stopping coding and rethinking", that is the reason I asked all these questions and putting things down, on paper to get a better overview.</p> <p>-The thing is, right now the basic "real world objects" as you put them make sense to me as rest resources /collections of resources, and they are correctly manipulated via POST, GET, UPDATE, DELETE , but I am having a hard time getting my head around the Rest approach for things that I do not instinctively view as "Resources".</p></li> </ul>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload