====== Auction implementation ====== * src: /home/dang/data/src/30_social_cloud_ws/01_jee_dev_ws/AuctionServiceWeb * git-ed ====== Feature Logs ====== * Resources * angularjs performance: https://www.exratione.com/2013/12/considering-speed-and-slowness-in-angularjs/ * filter results: http://stackoverflow.com/questions/13278371/angularjs-filter-negated/13450568#13450568 ===== ?? - Authentication ===== Resources: * http://stackoverflow.com/questions/18300192/how-to-proper-authenticate-an-angularjs-client-to-the-server ===== JavaEE Architecture ===== * http://antoniogoncalves.org/2013/10/29/several-architectural-styles-with-java-ee-7/ * http://www.hascode.com/2010/10/object-relational-mapping-using-java-persistence-api-jpa-2/#Named_Queries ===== JPA queries ===== * http://stackoverflow.com/questions/3424696/jpa-criteria-api-how-to-add-join-clause-as-general-sentence-as-possible * Restful API design ===== 20140711 - UA Test ===== * Create Item: Item seletion list shold contains only owner's items. * Creat Item: * Add attribute not work when creating Item. * Price attribute automatically added. ===== 20140703 - Angularjs Client: Access Areas ===== Refactor templates for different access areas: authn, not-authn, my auctions, all auctions... Resource: * http://www.frederiknakstad.com/2014/02/09/ui-router-in-angular-client-side-auth/ * http://www.frederiknakstad.com/2013/01/21/authentication-in-single-page-applications-with-angular-js/ * Child state inherit resolved dependencies: http://www.jvandemo.com/how-to-resolve-application-wide-resources-centrally-in-angularjs-with-ui-router/ * re-resolve parent state on state change: http://jsfiddle.net/jasallen/SZGjN/1/ ===== 20140702 - Query Auction Resource by Owner ===== Topics * Design Restful url and underlying Rest endpoints, Angularjs client. * Differentiate btw use-cases where users are logged in, place bids. Functions * Show all auction when not logged in * Show my auctions * Show others auctions, using filter: http://stackoverflow.com/questions/13278371/angularjs-filter-negated/13450568#13450568 Resources: * UI sidebar: http://stackoverflow.com/questions/19397140/collapsing-sidebar-with-bootstrap-3 * http://www.objectdb.com/java/jpa/persistence/retrieve * http://www.radcortez.com/java-ee-7-with-angular-js-part-1/ * http://www.slideshare.net/caroljmcdonald/rest-with-java-ee-6-security-backbonejs * http://www.infoq.com/articles/webber-rest-workflow * Combine with angularjs ui-router: http://www.frederiknakstad.com/2014/02/09/ui-router-in-angular-client-side-auth/ * Restful url design: https://www.google.de/search?q=http%3A%2F%2Fwww.infoq.com%2Fexamples%2Fwebber-rest-workflow&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a&channel=sb&gfe_rd=cr&ei=USK1U9roFNGGtQa6noGgCg#channel=sb&q=hierarchical%20restful%20url%20design&rls=org.mozilla:en-US:official * http://stackoverflow.com/questions/7833548/hierarchical-restful-url-design * http://stackoverflow.com/questions/9169268/hierarchical-restful-urls-still-preferred-in-terms-of-added-overhead-over-fl think it all depends on semantics and intentions. It seems like you're talking about a protected resource, not a publicly available one. In this case your communication is more explicit and has the least amount of surprise when a more verbose format is used: http://api.gallery.com/users/{user-id}/images/{image-id} If it's a public resource then it can be identified by image-id only and then the shorter format would be more logical: http://api.gallery.com/images/{image-id} share|edit|flag answered Feb 7 '12 at 0:32 Yuriy Zubarev 1,868613 add comment up vote 1 down vote I think that the second is more RESTful for the reason you state. The URL is a hierarchy. The user-id is not really part of the identification of the image, so why make it part of the identifier? Make an /users/{user-id}/images resource that returns a list of URLs in the form /images/{image-id} to list the images that the user has uploaded, and you have the best of both worlds.