- Better handling of the Accept headers etc & better exceptions
- Added the DataType enum
- Added unit test for GET /users/ via token
- Made Request fluent for more control
- Better fluent code!
- Fixed missing trailing slash in test
- Method to clear the cache
- Cleaning & Javadoc
- Cleaning & Javadoc
- Throw exception when querying the ID if not set
- Better Javadoc + details about threading
- Better users
- Added the LoggedUser class
- Unit tests for the User class
- Added missing override annotations as typos
- Maniphest Tasks
- T228: Users
- rLIBWFJVA5ffe88e3d84f: Added the User & LoggedUser classes
Add comments about why we are suppressing warnings and why a working fix is not possible
Explain more, read above
Why is the time being used here?
You more than likely shouldn't override built in functions, you may need it in the future
Read above, make seperate functions
Read above, prefix with get?
Why this request header?
Token looks like "Token XXXXXXXXX"
The warning is "the method doesn't need to be public", I suppress it because this is part of the public API (IntelliJ detects that the method is never used outside of the package, but doesn't know it's its purpose).
It feels like it would be redundant to add a comment about it every time it appears (which is probably going to be very often)... Do you want me to do it?
Because objects are removed/invalidated "after 5 minutes" for example.
In Java, it is standard to override toString, equals & hashCode. It's even expected from the standard API that you do it, more info
Was needed in an earlier version, I'm gonna remove it
So the server does not send HTML responses (by default, if none is specified, Java adds a "Accept: text/html" header)
In the API it just looks like XXXXX, the "Token " part is appended when you call Request.addToken(String) (see above)
What objects specifically?
Yes, in general, overriding concrete methods is a code smell.
Because the base method has a behavior associated with it that developers usually respect, changing that will lead to bugs when your implementation does something different. Worse, if they change the behavior, your previously correct implementation may exacerbate the problem. And in general, it's fairly difficult to respect the Liskov Substitution Principle for non-trivial concrete methods.
Your link states only what is required if you do override a function
Anything in the cache, currently only users but later posts, comments etc too
No, really, I'm serious, equals and hashCode exist in Java so they are overriden. In fact, some collections (such has HashSet or HashMap) will NOT work properly if you don't.
Also, overriding them the way I did it (only putting the ID for hashCode, etc) increases the performance of Java collections by a lot