Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Having worked with a few, I'll get right down to it</p> <ul> <li><p>Facebook</p> <ul> <li>GOOD: clean and relatively consistent. Performs well and most things logically make sense. FQL is pretty neat. XML and JSON options. No pre-conception of response format other than what you really need</li> <li>BAD: Changes often and without warning. 'official' api libraries are pretty atrocious. documentation of many calls are poor or missing. Non-standard authentication (some may call this good?)</li> </ul></li> <li><p>Myspace</p> <ul> <li>GOOD: open standards (oAuth authentication, Opensocial endpoint)</li> <li>BAD: often broken. Usage of oauth is very nonstandard and breaks most client libraries. official client libraries are terrible.</li> </ul></li> <li><p>Photobucket (disclaimer: I wrote the server side of the photobucket api)</p> <ul> <li>GOOD: open standard authentication (oauth). xml, json, even php serialized array format as response parameters. faithful REST (get/put/delete/post on 'noun' urls).</li> <li>BAD: not many client libraries. Architectural challenges with standard oauth libraries (users live on subdomains, calls must be made to subdomain, so url has to change).</li> </ul></li> <li><p>Twitter</p> <ul> <li>GOOD: pretty consistent (though api vs search api has diffs). Good REST practice. OAuth authentication as well as supporting oldschool Basic. </li> <li>BAD: error rate (pretty much consistent with rest of twitter though). Odd format of some return values (like their date format).</li> </ul></li> </ul> <p><strong>Ideal characteristics</strong></p> <ul> <li>I'm not sold on 'strict' REST. PUT and DELETE cause problems in some client languages. GET and POST seem to be sufficient with appropriate 'verbs'. Also, RPC-like function names are OK with me as long as they're logical and maybe even part of the URI. In that case, object IDS still need to be very consistent though.</li> <li>Standard authentication/authorization. Basic/Digest can be ok, but I'm a fan of OpenID/oAuth (or WRAP if you want to get bleeding edge). Rolling your own means you have to explain 100% of it, and potentially write client libraries for everyone.</li> <li>Standard datatypes. Make sure you are consistent about your datatypes (either 'true' or 1, not some mix), and support the most generic standards. Datetime should be ISO8601. Geolocation should 'look like' GeoRSS, etc. You <em>should</em> be able to create an XSD/relaxNG/whatever strict validator for your return types. Expect the same standards from your inputs.</li> <li>Simple return structure. there's some benefit to XML-RPC/JSON-RPC in that you kinda know what you're getting back, but in any case, if I cant easily parse your return type with JSON or something like PHP's SimpleXML and essentially serialize it to a consistent hash, I'm going to be pissed. </li> <li>Support extension/expansion without breakage. Dont code yourself into a corner and make it hard to add to your API. Try to make good decisions up front that you wont be changing constantly.</li> <li>Documentation! Make sure its good, and explains everything. Even then it won't be good enough, so make sure you have dedicated time to work on it and a supporting forum or whatever to keep it up to date. </li> </ul> <p>So that being said... something between Facebook and Twitter. Of course I'm partial to some of the stuff we have on Photobucket, but I also hate some of it.</p>
    singulars
    1. This table or related slice is empty.
    1. POWhat is the gold standard for website APIs? Twitter, Flickr, Facebook, etc
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USJustin
    1. USJustin
    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.
    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. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COA comment on the Twitter having "Good REST practice". Twitter does not use hypermedia to discover links and due to its use of generic media types the responses are not self-descriptive. It is far from being RESTful.
      singulars
      1. PO
      1. USDarrel Miller
    2. CO@Darrel - agreed but a pure RESTFUL service is only necessary if its going to be consumed and updated by robots - otherwise you spend too much time worrying about being RESTful instead of delivering a product IMO
      singulars
      1. PO
      1. USschmoopy
    3. CO@schmoopy Most static HTML websites are pure RESTful services. Are those only consumed by robots?
      singulars
      1. PO
      1. USDarrel Miller
 

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