Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>There are a couple of rough rules that I like to follow when designing webservices, especially for a exposed (where the services might be consumed by apps/users outside of some defined group) services.</p> <ol> <li>Maximal Units of work: Webservices (really any RPC service) is another piece of software running on a seperate (usually) machine, you have an expense in making the call to it (unlike a local function call) even if its on the same machine. Keep this in mind and build functions that were possible accept as much data as possible. Dont rely on roundtrips between servers to communicate and complete units of business operation. For instance, dont have a process "create account" which requires a call to "add user", "create account", "associate user with account", "update user details", "activate account" just to complete the process. Instead have a "createUserWithAccount" function that does it in one trip.</li> <li>Minimal Wait time: Remember these services are called inline, and if your process takes to long its possible for the process to be killed, either by an impatient user, a service in between or a watchdog process assuming there has been an error. You might consider preferring services which return "tickets" that the caller can then check on later. In most circumstances this is not strictly necessary, but for processes that might take more than a minute to run you might want this approach</li> <li>Well defined interfaces: Make sure your services have well defined, and preferably type agnostic definitions. Type agnostic defined here as making sure you use common types that are easily communciated, and have little chance of having unintended side effects for client implementers. Lots of people prefer to use XML as the basic of message transmission and hide all their details inside of that.</li> <li>Plan for changes: Services are in place for a long time (by design) and simultaneously exposed to external implementers. This means that they <em>will</em> need to change, but customer requirements may prevent you from doing it easily. When building your interfaces consider either versioning, or using transport encodings (like XML) which allow you to modify the data transmitted without modifying the calling interface. Look at how APIs (like the windows API) deal with this to get some ideas about how it can be problematic.</li> <li>Security as a first-class design goal: Service interfaces can be called by <em>anyone</em>. You have to expect that they will be called by all kinds of users, who may or may not have authenticated, and may or may not be malicious in nature. Plan security to occur at appropriate places, and don't rely on just one mechanism for verifying that everything is secure. There are several ways to approach security, and if your service is used internally you can relax some things but for public services you will need to consider how you want security to work and make sure it remains consistent across all of your services.</li> </ol> <p>Hope that helps.</p> <ul> <li>These are general strategies taken from Fowler and others. Just my take on how it should be approached. </li> </ul>
    singulars
    1. This table or related slice is empty.
    1. POSeparation of SOA services
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USGrayWizardx
    1. USGrayWizardx
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POSeparation of SOA services
      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. COGrayWizardx has obviously actually developed working services! The only point I would add to try to keep the interfaces which make sense to a Buisness User. eg "CreateCustomer" and not "InsertCnumToAccTable".
      singulars
      1. PO
      1. USJames Anderson
    2. COThank you for your very detailed answer.
      singulars
      1. PO
      1. USMike
    3. COAre you recommending that it should replace the whole client object, if editing a client to save calls back and forth between the client and the service?
      singulars
      1. PO
      1. USMike
 

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