StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Presumably you are writing a protocol layer that will understand your different message types. You will also need an application layer to parse the contents of the message. The different approaches you mention will shift the burden of parsing between these two layers. So for example:</p> <p><strong>Solution A</strong>: The protocol layer does all the parsing and returns the data and command. The application layer can just use the data. This is also known as the RPC pattern.</p> <p>Pros: You can validate your messages. You can map messages directly to application calls.</p> <p>Cons: If you need to make a change to the interface, your protocol changes.</p> <p><strong>Solution B</strong>: The protocol layer returns two values and a command. The application layer must use the command to parse the values into types.</p> <p>Pros: The protocol never changes.</p> <p>Cons: You can't validate messages. Your application code is more complicated.</p> <p><strong>Solution C</strong>: The protocol layer returns two known types and an command that must be parsed. The application layer can just parse the command and use the data.</p> <p>Pros: I can't think of any, seems like not a very good compromise.</p> <p>Cons: Leaves the parsing only partially done.</p> <p><strong>Solution D</strong>: The protocol layer returns known types (the way you implemented it) and a generic command. The application layer must look at the data it receives and convert the generic command into a specific command. This is similar to the REST architecture.</p> <p>Pros: Calls are distinct operations so that you could for example cache get responses.</p> <p>Cons: Complexity in the application layer</p> <p>The REST model is usually implemented differently than you have outlined. It uses HTTP GET, POST, PUT, DELETE messages to communicate arbitrary documents. Parameters are given as part of the URL. So for example:</p> <pre><code><insert airport="JFK" city="New York" country="USA" continent="North America" /> </code></pre> <p>becomes</p> <pre><code><insert URL="airport?city=Chicago">ORD</insert> </code></pre> <p>Or if you are using HTTP it becomes a POST request to an airport URL with a param of the city with the contents being information about the airport. Note that some of this becomes clearer with more compliated data where you have multiple elements and mixed types. For example if you wanted to send the airport abbreviation, long name, and altitude.</p> <p>I think the REST architecture could work quite well for the interface you describe. As long as all you need to do is support the CRUD operations. The are many sites that will give you the pros and cons of the REST architectural style.</p> <p>Personally I prefer the RPC style (Solution A) with some REST-ful attributes. I want the protocol to do the parsing work and validate the messages. This is typically how people implement SOAP web service interfaces.</p> <p>Your interface may look simple today but tomorrow one of your customers is going to ask you for a new call that doesn't fit the REST model so well and you'll find yourself wedging it into the existing four messages.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

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