We Keep Coding

Object builder that requires parameters based on other parameters

I am working with several external APIs on a business code that would be used by several developers that do not have the deep knowledge required to build meaningful queries to those APIs.
Those API retrieve data. For example, you can retrieve entities either based on their Key (direct access) or based on their Group (lists available entities). But if you choose to query by Key you have to provide an id, and if you query by Group you have to provide a groupName.
The APIs are bigger than that and more complex, with many possible use-cases. The main constraints are that:
Some parameters require the presence of other parameters
Some parameters put with other parameters produce no data at best, wrong data at worst.
I would love to fix the underlying APIs but they are outside our scope.
I think it might be good to enclose a bit those API and produced a APIService that can request(APIQuery query).
The basic thing I could do is to put conditions in the code to check that no developer instantiates the APIQuery with missing/incoherent parameters, however that would only be a runtime error. I would love for the developer to know when building their request that they can/cannot do something.
My two questions are:
Is there an extensible builder-like way to defer the responsibility of building itself to the object? Having 1 constructor per valid query is not a good solution, as there are many variables and "unspoken rules" here.
Is this even a good idea? Am I trying to over-engineer?

I'll answer your second question first:
Is this even a good idea? Am I trying to over-engineer?
The answer is an uncomfortable "it depends". It depends how bad the pain is, it depends how crucial it is to get this right. It depends on so many factors that we can't really tell.
And to your: is this possible?
Yes, a builder pattern can be extended to return specific builders when certain methods are called, but this can become complicated and mis-uses are possible.
For your specific example I'd make the QueryBuilder simply have two methods:
a byGroup method that takes a group value to filter on and returns a GroupQueryBuilder
a bykey method that takes a key value to filter on and returns a KeyQueryBuilder.
Those two classes can then have methods that are distinct to their respective queries and possibly extend a shared base class that provides common properties.
And their respective build methods could either return a APIQuery or distinct APIQueryByGroup/APIQueryByKey classes, whichever is more useful for you.
This can become way more complicated if you have multiple axis upon which queries can differ and at a certain point, it'll become very hard to map that onto types.

2 Classes with the same name, serving different purposes

The question I have is so weird that I couldn't even come up with a better title at the moment. Anyhow, I am looking for a way to name 2 classes but cannot figure out what would be the best way forward. I do understand this is an opinion based question but I'm stuck with this... so I would appreciate any opinion on this
Project: A
-> Class name: Call (This class will represent the call from one telephone to another) Other classes may/may not subclass this particular class and if so the name of these subclasses would probably relate somehow to the parent class (CallState, CallEndPoint, CallSomething). This Class will not know about the existence of the database, one could say this class will be part of the general telephony driver.
Project: B
-> Class name: Call? (This will represent the actual table in a database. The table will have some information about the call like call id, time it entered the system etc, but also other information that may/may not relate to the call). This class will serve essentially as a RowMapper.
Now, these 2 projects most likely will be combined down the line, and If I name the classes the same I would then end up with 2 same name classes in a single project serving 2 different purposes. Now if I was the only person to build this application I could probably digest this, but if multiple people start work on the application it will become confusing to others, especially if more classes will follow the same pattern.

I'm not entire sure what the question here is. Do you want to know if it's possible to give 2 classes the same name, or just whether it's a bad idea?
A convention that is often used for classes that are meant to model database entities, is to postfix the classname with Entity. So you could name the first class Call and the second CallEntity. This removes some ambiguity about the classes purposes. Most professional developers will also immediately make the assumption that the Entity class is supposed to represent something that is persisted.
However if you really insist on giving both classes the same name. That's perfectly possible, if you put them in separate packages. The package you put them in can also provide more clarity about the intent of the class. The first could be domain.model.Call, while the second could be domain.entity.Call
Hope this is somewhat helpful :)

Now, these 2 projects most likely will be combined down the line, and
If I name the classes the same I would then end up with 2 same name
classes in a single project serving 2 different purposes.
When inside a same application two classes with distinct responsibilities/data need to have the same simple name (that is without the package), you should indeed consider it as something to think of and very probably fix.
Of course you could define these classes in distinct packages but does it really solve your issue ? I don't think. It will make things less clear as client code could use the bad one and at each time developers manipulate/read Call in the code they have to wonder "which Call" they are currently copping with.
Today you have two distinct Call. With such permissive naming conventions, why not a new one in the future ?
Really, not a good idea.
The source of the problem is the way which you design your application.
You split the model in two pats : the agnostic persistence part in a class and the data persistence part in another class. It is a choice (that personally I avoid) but if you make this choice you have to go until the end : distinct clearly each class with a different name. This choice has to be visible and not hidden in a package name only.
For example :
Call (domain) and CallEntity (persistence) or in the reverse way CallDTO(domain) and Call(persistence)

Restful service naming conventions?

For a restfull service, does the noun can be omitted and discarded?
Instead of /service/customers/555/orders/111
Can / should I expose: /service/555/111 ?
Is the first option mandatory or are there several options and this is debatable?

It's totally up to you, I think the nice thing about having the nouns is that it helps you see from the URL what the service is trying to achieve.
Also taking into account that under customer you can have something like below and from the URL you can distinguish between order and quote for a customer
/service/customers/555/quote/111
/service/customers/555/order/111

One of the core aspects of REST is that URLs should be treated as opaque entities. A client should never create a URL, just use URLs that have been supplied by the server. Only the server hosting the entities needs to know something about the URL structure.
So use the URL scheme that makes most sense to you when designing the service.
Regarding the options you mentioned:
Omitting the nouns makes it hard to extend your service if e.g. you want to add products, receipts or other entities.
Having the orders below the customers surprises me (but once again, that's up to you designing the service). I'd expect something like /service/customers/555 and /service/orders/1234567.
Anyway, the RESTful customer document returned from the service should contain links to his or her orders and vice versa (plus all other relevant relationships).

To a certain degree, the "rules" for nameing RESTful endpoints should follow the same naming rules that "Clean Code" for example teaches.
Meaning: names should mean something. And they should say what they mean, and mean what they say.
Coming from there: it probably depends on the nature of that service. If you only can "serve" customers - then you could omit the customer part - because that doesn't add (much) meaningful information. But what if you later want to serve other kinds of clients?
In other words: we can't tell you what is right for your application - because that depends on the requirements / goals of your environment.
And worth noting: do not only consider todays requirements. Step back and consider those "future grow paths" that seem most likely. And then make sure that the API you are defining today will work nicely with those future extensions that are most likely to happen.

Instead of /service/customers/555/orders/111
Can / should I expose: /service/555/111 ?
The question is broad but as you use REST paths to define nested information, that has to be as much explicit as required.
If providing long paths in the URL is a problem for you, as alternative provide the contextual information in the body of the request.
I think that the short way /service/555/111 lacks consistency.
Suppose that /service/555/111 correspond to invoke the service for the customer 555 and the order 111.
You know that. But the client of the API doesn't know necessarily what the paths meaning are.
Besides, suppose now that you wish invoke the invoke the same service for the customer 555 but for the year 2018. How do that now ?
Like that :
/service/555/2018 would be error prone as you will have to add a parameter to convey the last path value and service/555/years/2018 will make your API definition inconsistent.
Clarity, simplicity and consistency matters.

According to me usage of noun is not necessary or comes under any standard,but yes it's usage helps your endpoint to be more specific and simple to understand.
So if any nomenclature is making your URL more human readable or easy to understand then that type or URL I usually prefer to create and keep things simple. It also helps your service consumer who understand the functionality of any service partially by name itself.

Please follow https://restfulapi.net/resource-naming/ for the best practices.

For a restfull service, does the noun can be omitted and discarded?
Yes. REST doesn't care what spelling you use for your resource identifiers.
URL shorteners work just fine.
Choices of spelling are dictated by local convention, they are much like variables in that sense.
Ideally, the spellings are independent of the underlying domain and data models, so that you can change the models without changing the api. Jim Webber expressed the idea this way
The web is not your domain, it's a document management system. All the HTTP verbs apply to the document management domain. URIs do NOT map onto domain objects - that violates encapsulation. Work (ex: issuing commands to the domain model) is a side effect of managing resources. In other words, the resources are part of the anti-corruption layer. You should expect to have many many more resources in your integration domain than you do business objects in your business domain.
Resources adapt your domain model for the web
That said, if you are expecting clients to discover URIs in your documentation (rather than by reading them out of well specified hypermedia responses), then its going to be a good idea to use URI spellings that follow a simple conceptual model.

Tangible example of Java Container - Specifically in NetBeans

In my search for this answer I have already read the following StackOverflow post.
Definition of a Java Container
My issue (lack of understanding ) at this point as a beginner is also learning the esoteric vocabulary. Therefore, even excellent examples often make little or no sense.
For this question please create an answer for the very, very, green beginner.
The actual question:
For the "Definition of a Java Container" give a tangible example, preferably using the NetBeans project tree, of what a Java Container is. A screen-shot would be very helpful for us extremely visual learners.
For example, if I were trying to answer the question "what is a container file" to a computer 101 student, I would probably not say something like this:"A container or wrapper format is a metafile format whose specification describes how different elements of data and metadata coexist in a computer file.
Rather, I would answer like this: "A container file is a ZIP file, MP3 or MP4 file. The reason it is called a container is that it actually contains many other files - much like a directory."
UPDATE
I found this Wikipedia article that I believe begins a decent explanation.
https://en.wikipedia.org/wiki/Container_%28abstract_data_type%29
For example, according to the above article, a simple example of a "container" in a programming language is an array. In object oriented programming languages fancier arrays such a Lists and Maps are also containers. However, for any beginning programmer reading this post, containers are also Classes that form a chain of inheritance (experts correct my terminology if I am wrong).
For beginners, if you do not know what inheritance is then go study that. There is another Wikipedia article to read.This whole article is describing "containers" in Java.
https://en.wikipedia.org/wiki/Java_collections_framework
To give the sort of example I was originally asking for, if you have NetBeans then go do this:
Create a new class, then inside of it create a new method, as shown below:
package InformationStorage;
public class MyClass {
public void MyMethod(){
}
}
Now, inside the method type the command "System", and then type a period. Like this:
["Screen shot from NetBeans"][3]
Notice the list of methods and other stuff included within "System". If you choose one (for example "out" as in System.out.), then when you type the period after "out" more sub-options appear, and so on.You will eventually end with something like "System.out.println();"
This is an example of Container Classes.

Frustrated-Me this question is posed just like your name haha. Anyway I will answer. There is allot of programming jargon that will not make sense to a beginner, I wouldn't worry about it at beginner stage. So yes there is a container which is the same as say a Collection (List,Map,Set...Array is maybe one too), which just contains other data members.
But then this term is used in another way in Java and other programming languages and frameworks.
What is a container in this sense? Well I guess I would say it's complicated thing that does allot of stuff for you in layman terms. You see, something like programming a website is very complex, and Java as a programming language can be considered verbose by some, this makes for a very difficult time for a developer. So there are all these fancy frameworks, for instance: Spring which may all share some similar concepts such as dependency injection, aspect orientated programming or whatever ever else. Even if you don't know what those things are they are just ways to help the programmer develop a complicated piece of software.
These concepts are often implemented in something that may be called a container. Basically you put your POJO (instances of a java class) in this container, and the container adds functionality to what you have done, via DI, or aspect orientated programing or something else. Usually these containers are built on design patterns such as the proxy or cake or MVC ect.
One might be able to say that a container in this sense does more than just storing your objects/data, but adds additional functionality to make your life easier.

Mongodb indexing should be redefined every time

I am really new to noSql and mongoDb and alot of questions are in my hand,
After searching I found Morphia, a ODM framework for java, in the documents of Morphia we can see some annotations like #Indexed that cause to create index for that specific column.
But the confusing issue for me is "datastore.ensureIndexes()" , document says
If you are using #Indexedannotation you shoud call datastore.ensureIndexes() after registering entity after application start.
So I can see my question in my mind after reading thatsentence, "we should redefine all indexes everytime?
I expect we can define indexes once somewhere like mongeez (mongeez is similar to liquibase) to run once at all.

Calling ensureIndexes() is virtually free if the indexes are already in place. You can (and arguably should) put this call directly after your mapping calls with no tangible impact. Any new indexes would get created but the existing indexes would essentially be no-ops.
For what it's worth, the morphia documentation can be found here.

So what you are referring to is the documentation here, and possibly then a little clarification of what that means along with the opinions that are offered in that document.
So as the document says, as per your quote, is that the index definitions you provide for your "Entity" classes are picked up by the .ensureIndex() method on the datastore, "when that is called in order to go and "re-create" all of those indexes.
The second point in the documentation defines this "as an example" along with the class mapping definitions like so:
Morphia m = ...
Datastore ds = ...
m.map(Product.class);
ds.ensureIndexes(); //creates all defined with #Indexed
And indeed that will be invoked every time your application is started, and some consider this best practice to ensure that all the definitions are "up to date" as it were. But also note, this is only an opinion.
As you seem to be pointing at, it would probably be better practice if you simply had some "post deploy" hook in which can be called when you actually "deploy" your application, or indeed "as needed" where you determine that re-defining your indexes is actually required.
It is generally one technique that I agree with, is to expose such a method as "callable" API for your application so that upon deployment, you can "script in" methods there to call that API function and actually re-define all your indexes (or even sub-set of) as you decide to do so.
So the actual interpretation is that using Morphia does not actually mean your indexes are re-defined every time the application is started "automatically", but if you do put the call to that .enssureIndexes() method somewhere where it will be called every time the application is started, then it will do so.
Don't call this in the same place as the class mappings. Put it somewhere else where you can control this, and the problem is solved.