Reputation
532
Top tag
Next privilege 1,000 Rep.
See votes, expandable usercard
Badges
2 7 15
Newest
 Benefactor
Impact
~58k people reached

  • 0 posts edited
  • 1 helpful flag
  • 19 votes cast
Feb
5
awarded  Benefactor
Feb
5
accepted API design dilemma: to REST or not to REST
Jan
29
awarded  Citizen Patrol
Jan
29
revised API design dilemma: to REST or not to REST
added 6 characters in body
Jan
29
comment API design dilemma: to REST or not to REST
Good point. I know in REST there should be no "traditional" login at all, and instead we should include authentication with each request. The problem is the UX guys came up with a login screen and I must call the server to check whether the user has an active account or not.
Jan
29
comment API design dilemma: to REST or not to REST
Login: So what about sending only the username in the login querystring through https + basic https authentication, and receiving the profile (without password) in the response?
Jan
29
awarded  Promoter
Jan
27
comment API design dilemma: to REST or not to REST
The POST hack looks contrived. POST should be used to push client generated entities to a collection, but here I'd be posting an empty request with no data. Notice how there is no state transfer. And of course it is not idempotent unless you want to live in denial. Tokens are not client generated, but server generated.
Jan
18
revised API design dilemma: to REST or not to REST
added 11 characters in body
Jan
18
asked API design dilemma: to REST or not to REST
Nov
9
awarded  Good Question
Apr
15
awarded  Yearling
Mar
31
awarded  Famous Question
Sep
24
awarded  Autobiographer
Sep
15
awarded  Famous Question
Sep
4
awarded  Nice Question
Aug
24
awarded  Good Question
Aug
20
comment Project structure: where to put business logic
Still there can be a lot of operations that do not belong in the entity, hence my concern about having too many classes and the problem of naming them. Such classes are just the encapsulation of a method, so why not just merge all the methods in a single class, whose single responsibility would be to manage operations related to the entity but depending on other classes.
Aug
20
revised Project structure: where to put business logic
added 17 characters in body
Aug
20
comment Project structure: where to put business logic
So you'd create a dedicated OrderTotalCalculator class stateless and with only one method. I like the naming, but if we create a class per domain operation needed, wont they proliferate and became hard to find? Would you consider merging this class with all the different OrderXXXOperation classes? If so, how would you name it? And finally, would you put those classes in the same package as the entity classes?