0

We're writing a series of RESTful services for our api. Well have /api/orders which is an endpoint for our orders system and /api/search for our search system.

In the past all of our services were SOAP services and we had methods that were called like verbs. So our orders system had addOrder(), getOrder(), addOrders(), getTracking(), etc..

So our new api will have /api/order/{id} and adds PUT and gets will be GET. We don't allow deleting or updating so we'll error handle for those and other HTTP verbs.

For my search we have getSearchResult() and we pass in a Criteria object with all of the criteria the user is searching with, and it can sometimes be a dozen properties they've set (from price, to price, images?, mark up, status, keyword, etc.). I know REST isn't a standard but if I want to stick w/ the architectural best practices I'm not sure exactly how I should be forming my endpoints.

/api/products/{searchCriteria} and we GET products fitting criteria
/api/search/{criteria} and we GET a "Search" or maybe 
/api/searchResult/{Criteria}
I'm assuming the criteria is going to be a JSON string.

Also I need to do a lookup of the Manufacturer and who ships based on zip code user is in. I'm a little confused between

/api/product/{pID}/manufacturer/{zip}
/api/manufacturer/{product}/{zip}
/api/manufacturer/{criteria} with criteria being a JSON string 
with product and criteria.

Being built in ASP.NET with Web API

Larry Grady
  • 469
  • 7
  • 24
  • What are sample criterias you want to issue? Why is there an own resoure for search and search result what is the difference between them? If you have many parameters to pass, consider to create a [view-like representation](http://stackoverflow.com/questions/35495385/rest-services-and-multiple-representations-of-same-object-with-different-fields) instead of appending each parameter only to the URI. GET requests should not contain a body and including JSON as query-parameter might not be the best option – Roman Vottner Mar 17 '16 at 18:58
  • Search is our main tool on the UI side. Customers want a replication of that functionality. So if someone is search for a product in our database they're going to type in a bunch of critera. Keyword = tent, fromPrice = 15, toPrice = 65, Status = Available and BackORdered, priceType = Jobber, ShippingDays = 10 days or less, Suppliers = [collection of Supplier ID Guids], Categories = [Collection of Gategory INT IDs], NewWithin = 60 Days, Colors = blue, HasImage=true, TopItem=true. That would be a single call returning back a list of products and product info/image links. – Larry Grady Mar 17 '16 at 19:47
  • search and search result were two options. We have several services. search services, order services, report services. So after our url we would start each service those uri's. /search , /orders , /reports . So could be like GET /search/searchresult/{criteria} or maybe it would be better GET /search/product/{criteria} – Larry Grady Mar 17 '16 at 19:49
  • Possible duplicate of [RESTful URL design for search](http://stackoverflow.com/questions/207477/restful-url-design-for-search) – jannis Mar 17 '16 at 22:07

0 Answers0