In my e-commerce project, I am building a set of REST APIs to list the categories and products from the catalog management system. A category can have sub-categories and a product can belong to a category or stand by itself.
- root_category
- sub_category
- product1
- product2
- product3
Here in this example, root_category contains sub_category & product2. The subcategory contains product1. product3 doesn't belong to any category.
Here are the possible use cases:
List all the products in the system.
/products
Get product details by id.
/products/{id}
Search for products by id, name or description (need to query by one of these criteria)
/products?searchTem={searchTerm}&q=[byId|byName|byDescription]
List all categories in the system.
/categories
5(a). List sub categories belonging to a particular category.
/categories/{id}/categories
5(b). List root level categories. (eg. root_category).
/categories/#root/categories
6(a). List products belonging to a category.
/categories/{id}/products
6(b). List products that don't belong to any category. ie., root level products (eg. product3).
/categories/#root/products
Please let me know your comments and suggest improvements for these REST URIs listed above. I am a little concerned about 5(b) and 6(b).Can those URIs be designed in a better way.
I think that looks reasonable, the only issue I have is the use of category id.
I would prefer to see a category name used, which is more user-friendly.
Category name has to be unique obviously.
Related
I must design an API to manage a Document entity: the originality of this entity is it can have two different ids:
id1 (number, i.e. 1234)
id2 (number, i.e. 89)
For each document, one and only one id is available (id1 or id2, not both)
Usually I solve this issue by using query parameters to perform some kind of "search" feature:
GET /documents?id1=1234
GET /documents?id2=89
But it works only if there is no sub-entity...
Let's say I want to get the authors of the documents :
GET /documents/1234/authors
Impossible because I can't know what type of id I get: is it id1 or id2 ?
GET /documents/authors?id1=1234
Not really REST I think because id1 then refers to the "Author" entity, not "Document" anymore...
GET /id1-documents/1234/authors
GET /id2-documents/1234/authors
Then you create two URIs that return the same entity (/author) not really REST compliant.
GET /documents/id1=1234/authors
GET /documents/id2=89/authors
It looks like a composite key created only for the API, it has no "backend" meaning. For me it sounds strange to create a "composite" key on the fly.
GET /document-authors?id1=1234
GET /document-authors?id2=89
In this case you completely lose the notion of tree... You end up with an API that contains only root entities.
Do you see another alternative ?
Which one looks the best ?
Thank you very much.
It seems to me that you're conflating two different resources here - documents and authors. A document has a relationship with an author, but they should be separate resources because the authors have existence from any individual document. With that in mind you need to ask whether your clients are searching for authors or documents. If it's authors, then they should be querying an authors API rather than a documents API.
e.g.For all the authors of documents with id1 89 or id1 1234 or id2 4444 you might query like this...
GET /authors?docId1=89&docId1=1234&docId2=4444
That should return a list of author representations. If people care about the documents themselves, the author representations could contain links to the documents.
Alternatively, if you're looking for documents then you should be querying that directly...
GET /documents?id1=89&id1=1234&id2=4444
What you're modelling as a sub-resource isn't really a subresource. It's a relationship between 2 independent resources and should be modelled as a set of links. Each document returned from the documents api should contain a set of authors links (if people really care about the authors) and vice versa from the authors to the documents.
Here's an opinionated solution from SlashDB, which allows for record filtering and traversing to related resources at the same time.
The example is similar to yours - two entities Artist and Album.
Let's identify the Artist first.
Artist by ID:
https://demo.slashdb.com/db/Chinook/Artist/ArtistId/2
Artist by Name:
https://demo.slashdb.com/db/Chinook/Artist/Name/Accept
An Artist may have issued Albums. The two entities are related. We allow extending the URL with the name of the related entity, like so:
https://demo.slashdb.com/db/Chinook/Artist/Name/Accept/Album
You can keep "going", say to get to the Tracks from those albums
https://demo.slashdb.com/db/Chinook/Artist/Name/Accept/Album/Track
And even continue filtering too i.e. only tracks, which are shorter than 300000 milliseconds:
https://demo.slashdb.com/db/Chinook/Artist/Name/Accept/Album/Track/Milliseconds/..300000
What's the deference between product catalog and category in Ofbiz ?
I think all of them is a group or set of product that have one or more common characteristics. But in Ofbiz's using one Catalog have many Category ?
Thanks!
They are similar, but catalog contains a list of categories with different purposes: home page categories, search categories, etc.
http://ofbiz.135035.n4.nabble.com/Product-Category-and-Catalog-td4636208.html
I have an Order, OrderItem and Stock entity. Basically, an order is created and then items can be added to the Order. An Order can have more than one item. Each item in the order is where the OrderItem comes into play.
My question is this: What attributes should I have for the order item class?
Currently I only have the primary key to identify it.
Should I have anything else?
I do not need any of the details for the items in the order as all the details for each item is in the Stock class.
Here is am image of what I am talking about:
What you 'need' to have will come down to wider requirements. Some things you might consider though:
You've included identifiers (keys) on the classes. You might also therefore want to include referentials (foreign keys) in Order Item - one each for Order.ordId & Stock.stkID respectively.
Do you need quantity? i.e. how many of each Stock item in each order? (e.g. 2 copies of "Lord of the Rings" if the stock items are books).
Date / time the order was placed?
Order status? (Confirmed/Shipped/Delivered/Cancelled etc.)?
Those are common things to find in such a scenario; which apply will depend on what you need to achieve.
hth.
I'm pretty new to Mongo. Just started a project using Mongodb as the database.
I'm not sure how should i design the following use-case to a document base database.
User-Case
1. Vendor/Distributor has a list of product on our system.
2. There's a standard price list of each product for any customers.
3. Vendor/Distributor also has customize price list of each of the product for each customer.
eg. CustA have a productA at different pricing from the standard and it's only available to him.
4. Some of the Product are only available through customize price, and I match those product with attribute public = false.
How should i work this out in document base database?
Current design i have is.
1. [Product Document] with embedded document of standard price list.
2. [Product_Price Document] with oneToMany link [Product Document] and oneToMany to [Customer Document]
3. [Customer Document].
With this Model, I'm facing problem with querying by paging.
Example I query the first 30 Product sorted by name. Then query [Product_Price Document] with the 30 ProductId that match, so that I have those customize price for that customer who login.
The problems come where by I couldn't query item that are customize to the user that is not available for everyone.
Is there a better way or design the schema or what should i do with the query?
I'm using PHP, Doctrine2, Symfony2
When you query the Product_Price_Document query it using both ProductID and current CustomerID. Or am I missing something?
Here's how I would structure it.
Have two collections:
- Products
- Vendors
Your products table would have the list of all your products and their standard price. Your vendors page would have an array of product ID's along with an override price in the case that they have a different price for that particular product.
If you are also tracking customers then you could make that a collection too and have a belongs to relationship almost to the vendors.
so in short:
collection.vendor:
{"name":'foo',"products":[{"_id":mongoId,"priceOveride":15.50},..]}
collection.products:
{"name":"bar","price":15.40}
Excellent resource for reading a bit more into the relationships which you can use:
Learn Mongo Interactively
So I have this problem I am trying to solve - I wonder if anyone can comment on/help me with the approach. The thing is, I have it partly solved, but with the rest I'm not quite sure.
Here's the deal:
I have a fairly large DB online which I want to load on first start of the App. After that I am only going to load it if new versions exist.
I use an xml parser to parse the data and enter all the data to my data model. The database consists of thousands of products, all described by various attributes.
Anyway, it's easy for me to save thousands of products in a database, then retrieving the data on demand.
I have a problem of how to categorize them and how to save the category data. There is a main category i.e. Hi-Fi which has several subcategories- let's say 'stereo', 'tuner', 'phone' and so on....
How to best save this info, that category a has 15 subcategories and each of these categories in turn has 30 products while securing performance and keeping process-time at a minimum. I don't want to check all 2000 Products whether I need to show them in a certain table view each time I open a new table view.
Any hints on the apporach are appreciated.
You'll need two entities: Product and Category.
Category has a to-many relationship called subcategories with a target entity of Category. The inverse relationship can be called parentCategory. Category also has a to-many relationship called products. Product would have an inverse relationship called category (or categories if a product can belong to multiple categories)
Now, you can get all the products for a given category by checking its products property. If you want to include all the products in the subcategories, you can do a fetch request with a predicate like this:
[NSPredicate predicateWithFormat:#"category == %# OR category IN %#", category, category.subcategories];
I think you can solve it by having a Core Data modal consisting of three entities: Product, Category and SubCategory.
Product has a relationship category with destination Category and a relationship subcategory with destination SubCategory.
Category has a to-many relationship products with destination Product and a to-many relationship subcategories with destination SubCategory.
SubCategory has a to-many relationship products with destination Product and a relationship category with destination Category.
When defining these relationships remember to assign the Inverse relationships as well.
Now you get a list of all products belonging to a specific category by just loading the Category in question and accessing the products property. It should also be possible to use NSFetchRequest for Product with a predicate specifying which category you want. Which is best regarding performance and memory requirements I can't say so you just have to test which approach works best.