Table of Contents
Auction implementation
- src: /home/dang/data/src/30socialcloudws/01jeedevws/AuctionServiceWeb
- git-ed
Feature Logs
- Resources
- angularjs performance: https://www.exratione.com/2013/12/considering-speed-and-slowness-in-angularjs/
?? - Authentication
JavaEE Architecture
JPA queries
- 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:
- 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:
- Combine with angularjs ui-router: http://www.frederiknakstad.com/2014/02/09/ui-router-in-angular-client-side-auth/
-
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.