StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POAPI Design: Expressing search criteria in XML
primarykey
Id
6130798
data
AcceptedAnswerId
6192813
AnswerCount
2
ClosedDate
CommentCount
4
CommunityOwnedDate
CreationDate
2011-05-25T20:52:28.817
FavoriteCount
1
LastActivityDate
2011-05-31T20:19:36.253
LastEditDate
2011-05-31T19:40:51.843
LastEditorUserId
83418
OwnerUserId
83418
ParentId
0
PostTypeId
1
Score
2
ViewCount
1162
LastEditorDisplayName
text
Body
Last year, my group developed a web service that included basic search functionality. All search conditions where combined with a boolean AND: <pre><code><conditions> <condition name="name1">value1</condition> <condition name="name2">value2</condition> <conditions> </code></pre> ... is equivalent to name1=value1 AND name2=value2 etc. Now, we have been asked to expand the search feature to allow for more complex searches. I see two plausible approaches: OPTION #1: Let users pass in their own SQL query (either full clause, or just the 'where). Examples: <pre><code><where>Cost = 5000.00 OR Cost > 5000.00</where> <query>SELECT cmis:name FROM cmis:document WHERE cmis:name LIKE '%test%'</query> </code></pre> Precedent: <ul> <li><a href="http://publib.boulder.ibm.com/infocenter/p8docs/v5r0m0/index.jsp?topic=/com.ibm.p8.ce.dev.net.doc/M_FileNet_Api_Query_SearchSQL_SetWhereClause_1_bb3a7a4f.htm" rel="nofollow">SearchSQL.SetWhereClause</a> in IBM's FileNet API </li> <li><a href="http://docs.oasis-open.org/cmis/CMIS/v1.0/os/cmis-spec-v1.0.html#_Toc243905420" rel="nofollow">Content Management Interoperability Services (CMIS) spec</a></li> <li>ADO uses this approach in various places. For example, <a href="http://msdn.microsoft.com/en-us/library/ee275540%28v=bts.10%29.aspx" rel="nofollow">recordset.Filter</a></li> </ul> Advantages: <ul> <li>Our schema stays simple. We could leave the "<conditions>" approach in place for the simple use cases, and add an alternative syntax. </li> <li>We'd just use the WHERE clause directly server-side (after scrubbing for sql injection) == cleaner code server side</li> <li>Follows industry standards (does it? CMIS, Microsoft ... anything from the Java world?)</li> </ul> Disadvantages: <ul> <li>Not exactly "elegant xml" (is there any such thing?). Potentially forces consumers of the service to do some hackish string manipulation on their side, rather than providing them with something more elegant.</li> </ul> OPTION #2. Revamp our <conditions> approach to allow more granular queries in the soap request. Example (from FetchXML): <pre><code> <filter type='and'> <condition attribute='lastname' operator='ne' value='Cannon' /> </filter> </code></pre> Precedent: <ul> <li><a href="http://msdn.microsoft.com/en-us/library/gg328117.aspx" rel="nofollow">FetchXML</a></li> <li><a href="http://ant-contrib.sourceforge.net/tasks/tasks/if.html" rel="nofollow">Ant gets close</a> with <if> / <else></li> </ul> Advantages: <ul> <li>Arguably more consistent with what an end user would expect (often the mark of a good API)</li> <li>Potential to give end users cleaner code</li> <li>Doesn't create dependency on SQL language / backend. Keeps it abstract</li> </ul> Disadvantages: <ul> <li>More server-side code required to reconstruct the XML into the SQL statement the user meant in the first place</li> </ul> I hope that the examples, precedent, advantages, and disadvantages give enough background to avoid subjective answers. I am looking for answers grounded in standards and best practices. My question is: are there definitive reasons for choosing one approach over the other in expanding an API?
Tags
<xml><web-services><architecture>
Title
API Design: Expressing search criteria in XML
singulars
PostAcceptedAnswerId
1. PO
 singulars
 PostTypePostTypeId
 PTAnswer
PostParentId
1. This table or related slice is empty.
PostTypePostTypeId
1. PTQuestion
UserLastEditorUserId
1. USJeff K.
UserOwnerUserId
1. USJeff K.
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. PO
 singulars
 PostTypePostTypeId
 PTAnswer
2. PO
 singulars
 PostTypePostTypeId
 PTAnswer
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 POAPI Design: Expressing search criteria in XML
 UserUserId
 USJeff K.
 VoteTypeVoteTypeId
 VTBountyStart
2. VO
 singulars
 PostPostId
 POAPI Design: Expressing search criteria in XML
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 POAPI Design: Expressing search criteria in XML
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId

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.