How to properly call my api and how to store and manage my data?
hey guys, i wanted to ask you for some advice. so im developing an api for learning purposes. so the api has to return a json with things that i should take on a hike. the idea is to call an endpoint, provide a distance and a season of the year, and then my api would return a list of items. ive just started and i already have some questions:
1. would it be better to provide my input using path variables (localhost:8080/api/v1/100/winter) or using query parameters(localhost:8080/api/v1/?distance=100&season=winter)?
2. currently i have just a simple controller, that returns "Hello world", but now i want to add a service which will hold all the logic. I have service interface and the implementation. Obviously, I will be injecting the interface, but the question is how? I can inject it through the constructor, through the setter, or through the class field. Which method is better?
3. How would you advise me to order/store the items needed for the hike (knife, hatchet, water, etc)? Im not sure I need to have a database, becaus this application is very primitive and there would be nothing to store. So i was thinking about using enums. I would have smth like BaseItems enum which would have the items that are always needed in every season (water, socks, food) and then I would have 4 more enums (SummerItems, WinterItems, etc) that would extend/inherit base items from the BaseItems enum, and would store additional items (tea, hat, woolen socks for winter, rainwear for autumn and summer, etc). Would it make sense?
Thanks for your advices and opinions
41 Replies
⌛ This post has been reserved for your question.
Hey @bambyzas! Please useTIP: Narrow down your issue to simple and precise questions to maximize the chance that others will reply in here./closeor theClose Postbutton above when your problem is solved. Please remember to follow the help guidelines. This post will be automatically closed after 300 minutes of inactivity.
1: Depends, path variables is more for actual restful apis where you are creating/updating/deleting objects, what you seem to have is a straight up calculation, so the query parameters are more correct tbh. But don't sweat it too much for now.
2: Always the constructor. This is more the general idea that once you called the constructor, you have a valid object. Not any of that initialize after the fact bullshit. So definitely constructor injection, and even better a DI framework like spring, dagger or guice
3: Don't use a database for this, but also not enums. They SHOULD be used for things that are actually constant. The things you take on a hike are not constant. If you decide tomorrow to add a screwdriver to your toolkit and it's not in your enum, that's a sign that an enum is a bad choice
No. You missed my point. I want to have predefined items for each season. So Id have X items for winter, Y for summer, etc
In object-oriented programming, the open–closed principle (OCP) states "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification";[1] that is, such an entity can allow its behaviour to be extended without modifying its source code.If you have to change the enum to add another item, that's a sign. Might not be now, might be for the next version
oh, i see
@tjoener but then whats the option for storing the items?
You can store it in code, but not using enums gives you the option for storing it anywhere
text files, databases
but u just said,
dont use DB for this
i dont get ur pointbecause it's simple
dbs are good if you want to change it while the application is running
if the list is constant, just stick it in a textfiles in src/main/resources and be done with it
ur saying
dont use DB bc its overkill but also dont store it in enums bc its too stubborn and troublesome to add one line of codeNot what I said
then, again, what wrong with enums?
if i need to add one more item to my items for the winter list, ill add one more word
well, if you don't use enums it doesn't matter where the "items" come from, a database, a file, or just added through the api
All without changing code
but look. it doesnt matter where do i keep my items (have separate enum for each season or have separate DB table for each season). If i need to add one item, i would add it to the enum or the db. it doesnt matter. i honestly dont understand what wrong with enums
Well I'm just speaking from experience. I would not put those things in enums because they might change, and having them stored separately makes more sense to me. I stick with the open-closed principles. And I also believe enums should not be used for things that aren't constant.
Okay. Finally its clear. But how is adding/removing an item to the enum is any different than adding/removing an item from Db table?
because to do the first you have to build and deploy your code again, and for the seocnd one you can do that without redeploying your app
Ahhh, okay. But if you add DB, then u have one more place where things can go wrong (i.e. DB server crashes, etc)
yes, but believe me, db servers are some of THE most stable pieces of software you will ever see
I've had some running for years
okay. but u get the idea. that the more complex you make something, the more places where stuff can go wrong u add
obviously
That's why I suggested you could use plain text files
ok. makes sense. but the the question about the code itself. can you help me understand the whole flow how it should work? controller calls service, service does what? call the repo?
i know people use dao/dto stuff sometimes. should i use it?
standard spring boot fair is a repository that holds data (usually db, could be anything, jus an interface), service that does business logic, and controller that translates to and from the web
If you don't know what for, no
you mean that if my logic isnt very complex, then i should use them? or what do u mean?
no, first your logic won't be complex, and if you don't know WHY you would need those objects, you don't need those objects
by saying WHY, u mean reasoning, or knowledge(i.e. what they are)?
knowledge
so basically just have my service call the repo, and thats it in terms of sctructure?
controller calls service, service calls repo
yeah, i skipped the controller
Don't recommend that
But ok
wdym?
* I don't recommend that
ah. i have controller on my app, its just that i skipped it and didnt mention it, when asking about overall code structure
ah
also last question about query params vs path vars. is this what those two boil down to?
Best practice for RESTful API design is that path params are used to identify a specific resource or resources, while query parameters are used to sort/filter those resourcesyes pretty much
but since im not specifying a resource nor filtering, then what?
well, you return what you need to take on your trip right? So call that a
loadout, there, name for your resource
So something like loadout/100km/ as a GET method might workand then add season as query param?
loadout/season/<season>/distance/<distance> can work, but query params are fine too
This is not really a resource, so the resource rules don't really matter💤 Post marked as dormant
This post has been inactive for over 300 minutes, thus, it has been archived.
If your question was not answered yet, feel free to re-open this post or create a new one.
In case your post is not getting any attention, you can try to use /help ping.
Warning: abusing this will result in moderative actions taken against you.