Databases
StackOverflow2013
Postsdbo
POHow to solve two REST problems: the interface document; loss of privacy in descriptive URLs
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POHow to solve two REST problems: the interface document; loss of privacy in descriptive URLs
    primarykey
    data
    text
    <p>Coming from a lot of frustrating times with WSDL/Soap, I very much like the REST paradigm, but am trying to solve two basic problems in our application, before moving over to REST. The first problem relates to the lack of an interface document. I think I finally see how to handle this situation: One can query his way down from a top-level "/resources" resource using various requests of GET, HEAD, and OPTIONS to find the one needed resource in the correct hypermedia format. Is this the idea? If so, the client need only be provided with a top-level resource URI: <a href="http://www.mywebservicesite.com/mywebservice/resources" rel="nofollow noreferrer">http://www.mywebservicesite.com/mywebservice/resources</a>. He will then have to do some searching and possible keep track of what he is discovering, so that he can use the URIs again efficiently in future to do GETs, POSTs, PUTs, and DELETEs. Are there any thoughts on what should happen here?</p> <p>The other problem is that we cannot use descriptive URLs like /resources/../customer/Madonna/phonenumber. We do have an implementation of opaque URLs we use in the context of a session, and I'm wondering how opaque URLs might be applied to REST. The general problem is how to keep domain-specific details out of URLs, and still benefit from what REST has to offer.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. USShaping
    1. USShaping
    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. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POHow to solve two REST problems: the interface document; loss of privacy in descriptive URLs
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POHow to solve two REST problems: the interface document; loss of privacy in descriptive URLs
      1. USmogsie
      1. VTFavorite
    3. VO
      singulars
      1. POHow to solve two REST problems: the interface document; loss of privacy in descriptive URLs
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI'm having trouble finding the question(s) to answer here. For the first one, are you asking how to make your RESTful services discoverable as opposed to simply providing documentation to the users? For the second, it really sounds like you are mixing URL rewriting up with calling web services...
      singulars
      1. POHow to solve two REST problems: the interface document; loss of privacy in descriptive URLs
      1. USNotMe
    2. COIn the first question, I think that discoverability is not the issue, if you have only one URI naming the service's head resource. I'm asking specifically about access-efficiency, which appears always to be ramiform and potentially deep in the resource graph. The repeated drilling might become a problem. Caching may help, and may even solve this problem. In the second question, I am asking how to rewrite URLs to be opaque/private, and still make a REST architecture work. Does anyone have specific experience with this situation?
      singulars
      1. POHow to solve two REST problems: the interface document; loss of privacy in descriptive URLs
      1. USShaping
    3. COActually the problem is more basic. Machine-to-machine interaction needs to be as close to automatic as possible. When you load a WSDL document, all the boiler plate--calls, parameter names, parameter order, types of parameters has been worked out for you. You plug in your arguments, and the operation just works, returning a know type. A non-programmer can simply follow these constraints and get the operation to work. With REST, my client needs to write some kind of crawler to find the resource(s) he needs, and then possibly also remember the name of the resource(s) (retain state).
      singulars
      1. POHow to solve two REST problems: the interface document; loss of privacy in descriptive URLs
      1. USShaping
 

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