Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I would use a REST API, similar to the way Flickr's API works: <a href="http://flickr.com/services/api/" rel="nofollow noreferrer">http://flickr.com/services/api/</a></p> <p>It is fairly simple to create and maintain, the biggest downsides are that it takes a lot of documentation (but pretty much any way you do an API will have this issue) and that robust error handling is a must.</p> <p>But in my opinion, it's the best way to create an API that is the closest to cross platform/cross language.</p> <p>More information here: <a href="http://www.xfront.com/REST-Web-Services.html" rel="nofollow noreferrer">http://www.xfront.com/REST-Web-Services.html</a></p> <p><strong>Update</strong>: The submitter added the following to the post:</p> <blockquote> <p>I am not opposed to making it a straight web service then giving out a WSDL file. But what if I want the client API to do some logic, encryption, error checking or so on?</p> </blockquote> <p>I personally do not like using SOAP (using a WSDL). There is a lot of inherent overhead to using SOAP, both on the server and the client. I think that is why you see more and more public API's being written using REST. It really lowers the barrier to entry to the lowest common denominator, allowing anything that can use basic HTTP (GET and POST (also PUT and DELETE for the "proper" way of doing it)) to use the API. </p> <p>Some more examples of public API's written using REST: <a href="http://apiwiki.twitter.com/" rel="nofollow noreferrer">twitter</a>, <a href="http://vimeo.com/api" rel="nofollow noreferrer">vimeo</a>, <a href="http://googlesystem.blogspot.com/2008/04/google-search-rest-api.html" rel="nofollow noreferrer">Google</a></p> <p>As far as expecting the client that is using your API to do anything, you can't! There is nothing you will be able to do to ensure that the consumer of the API will do anything right. That's why robust error handling is so important. You must check and double check any and everything that comes from the client. You must always be suspicious of it, and even assume that it is malicious. There really is no good way around that fact.</p> <p><strong>Update 2:</strong> the submitter added the following to the post:</p> <blockquote> <p>My original idea was to create a DLL or Assembly in .NET, then the client is making calls into this code that is running client side. This code may talk via any communications protocol back to the server, but my API would be running on their box. I guess REST does not really accomplish this. It seems like in REST everything is still an HTTP post. It is almost web services with out soap.</p> </blockquote> <p>You can certainly do this, but that is only going to work for .NET languages, meaning that your cross-platform and cross-language benefits are out the window. And still, in the end, are you really preventing anything? The developer is going to either use your remote API, or your local DLL or Assembly. Either way, he is going to have to know how to use it and use it right, otherwise you are going to throw an error. All you are really doing is changing where the errors get thrown from. Which may be important to you (if so, mention why) but really isn't changing anything in the equation.</p> <p>But you are somewhat correct in saying REST is kind of like web-services without the SOAP. Technically REST is web-services too, its just that web-services have come to generally mean SOAP. It really is a different way of achieving the same thing. The biggest differences are though that it takes more programming and thought on your side (and potentially more programming on the client side) but you trade that for robustness, less overhead in both the consumer and the server, and the widest possible audience for the API. It really is the lowest common denominator. </p>
    singulars
    1. This table or related slice is empty.
    1. POLanguage Agnostic API
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USJoeyC
    1. USRyan Guill
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POLanguage Agnostic API
      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. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI responded to your answer. I like the idea, but I was thinking of something I had more control over.
      singulars
      1. PO
      1. USAnthony D
    2. COawesome. You should see my response to your response ;) HTH
      singulars
      1. PO
      1. USRyan Guill
 

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