Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Rule 1. REST is about objects. Not methods.</p> <blockquote> <p>The REST "resources" have become too fragmented </p> </blockquote> <p>False. Always false. REST resources are independent. They can't be "too" fragmented.</p> <blockquote> <p>instead of having just a Device resource I now have all these resources:</p> <p>Device DeviceStatus Driver DriverStatus </p> <p>While these all make sense from a [RESTful] point of view, is it normal to have a lot of sub resources that each map to a separate python class ?</p> </blockquote> <p>Actually, they don't make sense. Hence your question.</p> <p>Device is a thing. /rest/environments/{id}/devices/{deviceId}</p> <p>It has status. You should consider providing the status and the device information together as a single composite document that describes a device.</p> <p>Just because your relational database is normalized does not mean your RESTful objects need to be precisely as normalized as your database. While it's simpler (and many frameworks make it very, very simple to do this) it may not be <em>meaningful</em>.</p> <blockquote> <p>consider the connection to be always existing, hence the use of "PUT" , but would that be bad thing considering "PUT" should be idempotent ?</p> </blockquote> <p>Connections do not <em>always</em> exist. They may come and go. </p> <p>While a relational database may have a many-to-many association table which you can UPDATE, that's a peculiar special case that doesn't really make much sense outside the world of DBA's. </p> <p>The connection between two RESTful things is rarely a separate thing. It's an attribute of each of the RESTful things.</p> <p>It's perfectly unclear what this "connection" thing is. You talk vaguely about it, but provide no details.</p> <p>Lacking any usable facts, I'll guess that you're connecting devices to drivers and there's some kind of <code>[Device]&lt;-[Driver Status]-&gt;[Driver</code>] relationship. The connection from device to driver can be a separate RESTful resource.</p> <p>It can just as easily be an attribute of Device or Driver that does not actually have a separate, visible, RESTful resource. </p> <p>[Again. Some frameworks like Django-Piston make it trivial to simple expose the underlying classes. This may not always be appropriate, however.]</p> <blockquote> <p>are there good rules /tips to inteligently define a set of resources from a set of methods ?</p> </blockquote> <p>Yes. Don't do it. Resources aren't methods. Pretty much that's that.</p> <p>If you have a lot of methods -- outside CRUD -- then you may have a data model issue. You may have too few classes of things expressed in your relational model and too many stateful updates of things.</p> <p>Stateful objects are not inherently evil, but they need to be examined critically. In some cases, a PUT to change status of an object perhaps should have been a POST to add to the history of an object. The "current" state is the last thing POSTed.</p> <p>Also.</p> <p>You don't have to trivialize each resource as a class of things. You can have resources which are collections. You can POST a fairly complex document to a composite (properly a <strong>Facade</strong>) "resource". That complex document can imply several CRUD operations in the database. </p> <p>You're wandering away from simple RESTful. Your question remains intentionally murky. "method rich application core" doesn't mean much. Without concrete examples, it's impossible to imagine.</p> <blockquote> <p>Api logic influencing application structure</p> </blockquote> <p>If these are somehow different, you're probably creating needless, no-value complexity.</p> <blockquote> <p>is it good practice to apply separation of concerns ? </p> </blockquote> <p>Always. Why ask?</p> <blockquote> <p>a lot of this seems to come from my confusion about how to map a rather method rich api to a Rest-Full one , where resources should be nouns, not verbs : so when is it wise to consider an element a rest "resource"?</p> </blockquote> <p>A resource is defined by your problem domain. It's usually something tangible. The methods (as in "method-rich API" are usually irrelevant. They're CRUD (Create, Retrieve, Update, Delete) operations. If you have something that's not essentially CRUD, you have to STOP coding. STOP writing code, and rethink the API to make it CRUD-like. </p> <p>CRUD - Create-Retrieve-Update-Delete maps to REST's POST-GET-PUT-DELETE. If you can't recast your problem domain into those terms, stop coding. Stop coding until you get to CRUD rules.</p> <blockquote> <p>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> </blockquote> <p>Correct. They're already part of your problem domain. You already have this class defined. You're just making it available through REST.</p> <hr> <p>Here's the point. The problem domain has real-world objects. You have class definitions. They're tangible things. REST transfers the state of those tangible things.</p> <p>Your software may have intangible things like "associations" or "links" or "connections" other junk that's part of the software solution. This junk doesn't matter very much. It's implementation detail. Not real-world things.</p> <p>An "association" is always visible from both of the two real-world RESTful resources. One resource may have an foreign-key like reference that allows the client to do a RESTful fetch of another, related object. Or a resource may have a collection of other, related objects, and a single GET retrieves an object and a collection of related objects.</p> <p>Either way, the real-world RESTful resources are what's available. The relationship is merely implied. Even if it's a physical many-to-many database table -- that doesn't mean it <strong>must</strong> be exposed. [Again. Some frameworks make it trivially easy to expose everything. This isn't always good.]</p>
    singulars
    1. This table or related slice is empty.
    1. POPython object hierarchy, and REST resources?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USS.Lott
    1. USS.Lott
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POPython object hierarchy, and REST resources?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThanks a lot S.Lott! Lots of bad phrasing on my part: I modified all the questions for less "murkiness", and I tried to address some of your points.
      singulars
      1. PO
      1. USMark Moissette
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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