I am writing huge Rest API, to make it easily discoverable, i am making the pattern like this way.
http://127.0.0.1:8000/membership/api/v1/make-a-payment
But i notice poeple used to make the pattern like this way: http://127.0.0.1:8000/ap/v1/blabla
Can you anyone tell me what is the best practice?
is it ok writing pattern like this way? http://127.0.0.1:8000/membership/api/v1/make-a-payment ?
I just trying to make it easily discoverable by swegger docs.
What is your opinion?
Can you anyone tell me what is the best practice?
REST doesn't care what spelling conventions you use for your resource identifiers.
RFC 3986 defines paths and path segments.
The path component contains data, usually organized in hierarchical form...
Many will therefore choose to align their identifier hierarchy with the hierarchy of their resources. It's not required that you do so, but as an organizing principle it's not bad, and of course no worse than any other arbitrarily selected convention.
For example, a common practice is that collection items will have identifier spellings subordinate to the identifier of the collection itself.
/photos <-- the collection
/photos/17 <-- an item in the collection
So you might reasonably ask whether api is one item of several in a membership collection, or if membership is one item of several in an api collection.
You might also want to review relative resolution and how dot-segments can be used to navigate up the hierarchy. If references between memberships and some other idea are more common than references between api and some other idea, then the spelling /api/membership may prove to be the more convenient choice.
I think a good guideline is this: any path segment implies the existence of siblings at the same hierarchical level. /membership/api implies the existence of /membership/something-that-isnt-api -- otherwise, why not just /membership ?
is this a valid use case?
For example to access a calendar from multiple sources, such as facebook or google.
Whereby each of these have their own strategies to call the underlying specific APIs?
Due to the use of APIs and not a lower level algorithm would this be more suited towards a DI approach?
Thanks
I think that's a reasonable approach to take. You basically abstract away the underlying implementation with your interface and can either grab your implementation through an abstract factory, DI, or just a basic map of strategies.
I have been trying to understand componentization(contrasting to the OOP concepts and also called component oriented programming), in relation to C++.
I have researched regarding this on internet but there were very little structured information available. The windows COM object seems pretty componentized. I have found http://c2.com/cgi/wiki?ComponentDefinition useful.
What could be the best and simple C++ code example, to illustrate the componentization concept?
I have a few high level ideas,like:
I have an English word. A word is made up of several symbols or
characters. Now, each character can be of several types like
alphabetic, numeric, punctuation, whitespace, etc. So, each
alphabet,number,etc. represent the fundamental components, based on
which, a word will be formed and will come into existence.
The word becomes an aggregate component(of symbols), based on which
a sentence will be formed and so on.
The protons, neutrons and electrons are individual agrregate components which form an atom.
Then, how is composite design pattern different from the componentization concept?
Please guide me.
Thanks.
'Composite' as you mentioned is a design pattern. A design pattern is a problem-solution pair applicable during the design of a piece of software.
If I understand your interpretation of the term 'componentization' correctly, it is an architectural princicple which is followed in a higher abstraction level than the design to define the structure of the SW.
(If you are interested in precisely what I mean by architecture, please refer this paper which tries to define the terms design/architecture formally.)
If you get slightly more deep, 'Composite' helps to treat the container and the contents with the same interface. e.g, if you apply 'composite' pattern in your example, you could define an interface 'particle' and then can treat atom/electron/proton/neutron as particles and at the same time the container/content relationship is also maintained. This is a very specific problem-solution pair which can arise only in certain situations.
However, 'Componentization' can be applicable in more broader situations and you are not bothered if there is any container-content relationship in the first place. Even if there is such a relationship between the components, you don't care to treat them with the same interface.
Now I'm developing a specialized vector editor. Can you tell me where I can see a good example (only C++ language ) of source (not standard book example) implementation composite and visitor pattern together.
Composite + visitor isn't such a popular pair, in most cases you can see composite + iterator ... so you will have to try add them by your own hands, but it shouldn't be hard. In both patterns you have inteface implemented by concrete classes, so you have to fill your composite with visitor ideas
http://sourcemaking.com/design_patterns/composite/cpp/2
http://sourcemaking.com/design_patterns/composite/cpp/1
http://sourcemaking.com/design_patterns/visitor
gl :)
A quick google search gave me these implementation examples of Composite Pattern:
C++ example for Composite Design Pattern
Composite design pattern
Composite design pattern - multiple container classes
Composite Pattern Made as C++ Component
This example source code is based upon the file system example found in the book Pattern Hatching: Design Patterns Applied, by John Vlissides, which uses Composite and Visitor. (The code includes external iterator that is not in the book).
Free slides detailing the example from the book are at Designing with Patterns.
So, I've come back to ask, once more, a patterns-related question. This may be too generic to answer, but my problem is this (I am programming and applying concepts that I learn as I go along):
I have several structures within structures (note, I'm using the word structure in the general sense, not in the strict C struct sense (whoa, what a tongue twister)), and quite a bit of complicated inter-communications going on. Using the example of one of my earlier questions, I have Unit objects, UnitStatistics objects, General objects, Army objects, Soldier objects, Battle objects, and the list goes on, some organized in a tree structure.
After researching a little bit and asking around, I decided to use the mediator pattern because the interdependencies were becoming a trifle too much, and the classes were starting to appear too tightly coupled (yes, another term which I just learned and am too happy about not to use it somewhere). The pattern makes perfect sense and it should straighten some of the chaotic spaghetti that I currently have boiling in my project pot.
But well, I guess I haven't learned yet enough about OO design. My question is this (finally. PS, I hope it makes sense): should I have one central mediator that deals with all communications within the program, and is it even possible? Or should I have, say, an abstract mediator and one subclassed mediator per structure type that deals with communication of a particular set of classes, e.g. a concrete mediator per army which helps out the army, its general, its units, etc.
I'm leaning more towards the second option, but I really am no expert when it comes to OO design. So third question is, what should I read to learn more about this kind of subject (I've looked at Head First's Design Patterns and the GoF book, but they're more of a "learn the vocabulary" kind of book than a "learn how to use your vocabulary" kind of book, which is what I need in this case.
As always, thanks for any and all help (including the witty comments).
I don't think you've provided enough info above to be able to make an informed decision as to which is best.
From looking at your other questions it seems that most of the communication occurs between components within an Army. You don't mention much occurring between one Army and another. In which case it would seem to make sense to have each Mediator instance coordinate communication between the components comprising a single Army - i.e. the Generals, Soldiers etc. So if you have 10 Army's then you will have 10 ArmyMediator's.
If you really want to learn O-O Design you're going to have to try things out and run the risk of getting it wrong from time to time. I think you'll learn just as much, if not more, from having to refactor a design that doesn't quite model the problem correctly into one that does, as you will from getting the design right the first time around.
Often you just won't have enough information up front to be able to choose the right design from the go anyway. Just choose the simplest one that works for now, and improve it later when you have a better idea of the requirements and/or the shortcomings of the current design.
Regarding books, personally I think the GoF book is more useful if you focus less on the specific set of patterns they describe, and focus more on the overall approach of breaking classes down into smaller reusable components, each of which typically encapsulates a single unit of functionality.
I can't answer your question directly, because I have never used that design pattern. However, whenever I have this problem, of message passing between various objects, I use the signal-slot pattern. Usually I use Qt's, but my second option is Boost's. They both solve the problem by having a single, global message passing handler. They are also both type-safe are quite efficient, both in terms of cpu-cycles and in productivity. Because they are so flexible, i.e. any object and emit any kind of signal, and any other object can receive any signal, you'll end up solving, I think, what you describe.
Sorry if I just made things worse by not choosing any of the 2 option, but instead adding a 3rd!
In order to use Mediator you need to determine:
(1) What does the group of objects, which need mediation, consist of?
(2) Among these, which are the ones that have a common interface?
The Mediator design pattern relies on the group of objects that are to be mediated to have a "common interface"; i.e., same base class: the widgets in the GoF book example inherit from same Widget base, etc.
So, for your application:
(1) Which are the structures (Soldier, General, Army, Unit, etc.) that need mediation between each other?
(2) Which ones of those (Soldier, General, Army, Unit, etc.) have a common base?
This should help you determine, as a first step, an outline of the participants in the Mediator design pattern. You may find out that some structures in (1) fall outside of (2). Then, yo may need to force them adhering to a common interface, too, if you can change that or if you can afford to make that change... (may turn out to be too much redesigning work and it violates the Open-Closed principle: your design should be, as much as possible, open to adding new features but closed to modifying existent ones).
If you discover that (1) and (2) above result in a partition of separate groups, each with its own mediator, then the number of these partitions dictate the number of different types of mediators. Now, should these different mediators have a common interface of their own? Maybe, maybe not. Polymorphism is a way of handling complexity by grouping different entities under a common interface such that they can be handled as a group rather then individually. So, would there be any benefit to group all these supposedly different types of mediators under a common interface (like the DialogDirector in the GoF book example)? Possibly, if:
(a) You may have to use a heterogeneous collection of mediators;
or
(b) You envision in the future that these mediators will evolve (and they probably will). Hence providing an abstract interface allows you to derive more evolved versions of mediators without affecting existent ones or their colleagues (the clients of the mediators).
So, without knowing more, I'd have to guess that, yes, it's probably better to use abstract mediators and to subclass them, for each group partition, just to prepare yourself for future changes without having to redesign your mediators (remember the Open-Closed principle).
Hope this helps.