Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>"Service" vs "API" is a pretty vague question. Often, the two terms are used interchangeably. "REST" vs "RPC" is a little easier to explain.</p> <p>Usually with REST, a URL represents a specific resource such as a "user", an "account", etc.. Typically, you can create/retrieve/update/delete these resources by using the HTTP methods POST/GET/PUT/DELETE. To update the profile for user 1125 you might send the following:</p> <pre><code>POST /user/1125 HTTP/1.1 Host: wherever.com Content-type: application/x-www-form-urlencoded firstName=Davey&amp;lastName=Jones&amp;email=dj%40thebrineydeep.com </code></pre> <p>Anything you wanted to do with user 1125, you would send a request to the same URL. There are exceptions and variants of this idea, but that's the crux of it.</p> <p>RPC services is more like just using a function library, which is bound to a specific URL. You might have a whole bunch of related functions all bound to the URL <code>/services/json</code>. Then if you wanted to change the profile for old Davey Jones, you would:</p> <pre><code>POST /services/json HTTP/1.1 Host: wherever.com Content-type: application/json { "jsonrpc": "2.0", "id": 1, "method": "setProfile", "params": [ 1125, { "firstName": "Davey", "lastName": "Jones", "email": "dj@thebrineydeep.com" } ] } </code></pre> <p>I personally like JSON-RPC better because:</p> <ul> <li>I don't have to try and fit all of my function calls into some kind of resource-to-url mapping that might not make sense</li> <li>We don't try to overload the HTTP response codes to indicate API errors. Every request returns a 200 response (unless there is a server error) and you know from the response body whether you got an error or not. JSON-RPC is particularly good at being explicit about error conditions.</li> </ul> <p>Sometimes REST is better because:</p> <ul> <li>Sometimes the resource-to-URL mapping fits really well</li> <li>It is more intuitive for third parties to understand</li> <li>It offers a simpler model for just retrieving easily-identified information</li> </ul> <p>I don't think either one is any easier to code.</p> <p><strong>Edit</strong> I changed the REST example to use the more common form-encoded data instead of JSON. But of course you can specify any data format you like with REST. It isn't carved in stone.</p>
    singulars
    1. This table or related slice is empty.
    1. POWeb services - REST vs PHP JSON RPC
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USslashingweapon
    1. USslashingweapon
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POWeb services - REST vs PHP JSON RPC
      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 for the reply .. Does it make sense to create a "REST wrapper" around the rpc services ... like if you are accessing the user profile "user1" then the user would type - " http://xyz.com/user1 ".. This would internally call the rpc-service to get the resource with the id "user1"??
      singulars
      1. PO
      1. USFox
    2. COIt is doable, provided you have an easy mapping from REST<->RPC. Even so, it is extra work. You have to ask yourself what you have to gain from it. I would usually go with just one or the other.
      singulars
      1. PO
      1. USslashingweapon
 

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