|
Youtube is a bit of an ass with that.. many channel had their advertising money cancelled or even worse, stolen due to spurious copyright claim...
|
|
|
|
|
Super Lloyd wrote: I am just freeloading here!
What would you call what YouTube is doing?
|
|
|
|
|
well... good question... hahah
though it does offer those "content creator" an expression medium with a wide reach...
but when it cancel the monetisation or even take it away..
at the very least it's unethical...
|
|
|
|
|
Super Lloyd wrote: though it does offer those "content creator" an expression medium with a wide reach...
How does Facebook compare with that?
And I would use "content creator" loosely in both instances (YT/FB)...but I see you already did put that term in quotes. 
|
|
|
|
|
I sponsor two creators on Patreon, and feel good about it. Right now it is only $11 a month, and this way I can choose how I sponsor.
For me it's better then Netflix subscription.
|
|
|
|
|
Hi.
I compare the "state" of YT with the Music-Production in the Ninties.
The "democtratization" of Selling CDs and "cheap productions", lead to a oversaturation and the disruption of the Market.
The same is Happening to YT.
For me, the most annoying Part, it is all about "begging" for Money...
If the Channel is BIG, it is only selling Stuff.
If it is too small, it is "grinding" for any Penny, Nickle or how the smallest Coin in Your area is called...
And so Parteon comes too the rescue... Wait a moment... it is just too grind somewhere else... hmmmm...
So the similarity to the Music-Producer and the "Content-Creator", ist there.
Only the "hyped" and "pushed" can earn Money, all the rest is investing, just to keep it running.
And here is what YT was "giving" away, free Money for "the Creative" ones.
"But now, the free Lunch is over..."
You can see it on the YT, how Creators went to "extrimism" too stay in the Business.
Likes are bought, shady secondary Markets opened up...
For me Patreon is more a secondary Market for YT.
YT, as a Platform, is well established, now all the little ones can ask for Money, but keep it going is another Story.
BTW in Germany there is a Profession named "Content-Creator/Mediengestalter", who is capable to use all sorts of Industrial Application to manipulate "Pixels" and such...
I like to call them "Pixel-Schubser".
Translates to "Pixel-Pusher".
I saw it in real live... It was really hard to Push a Red Pixel, one by one to the right...
I can´t do this Work, my bad Spine... It is too hard... 
c.u. @all Next Year 
|
|
|
|
|
RESTful API Designing guidelines — The best practices - By[^]
Comments?
Personally, I tend to disagree, particularly with the pluralized resource name and occasionally I find exception to the "noun" vs. "verb" rule, especially when I'm using a POST to provide a bunch of structured data for a GET (yes, it happens, particularly in my case when writing CC/ACH payment API's) and since GET is not supposed to have a body, and I don't want all that data in the URI, I revert to a POST with an endpoint like "getServiceFee".
But I'm curious what y'all think about how sticky the "guidelines" in that post should be.
|
|
|
|
|
More like guidelines really.
Never let other people's rules outweigh your own common sense.
And never pluralize anything.
Think in terms of collections and collective nouns -- catalog, inventory, workforce, etc.
modified 20-Dec-19 8:40am.
|
|
|
|
|
I think you mean:
And never pluralize anythings.
|
|
|
|
|
PIEBALDconsult wrote: never pluralize anything.
PIEBALDconsult wrote: More like guidelines really
ITYM "guideline".
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I finished my first WebAPI based project with all POST and no GET for the reason you mentioned.
But now I'm keeping it moderate. I override it when required, it's just a guideline.
If someone argues on the principle of REST, then say you are doing GraphQL.
|
|
|
|
|
Sounds good to me. Provided it's guidelines and not rules.
I think everyone has had that problem with GET vs POST.
I don't mind pluralizing names, if you do it's because of what you're used to.
It makes logical sense, and is also ISO standard.
|
|
|
|
|
Caveat: I don't have enough experience in this area to be qualified to pass judgment.
When consuming someone's API, I prefer explicitness. So, I think I like your approach of "getServiceFee".
However, that's a property of some larger entity, so I could certainly see the argument that one should just get the entity and look for ServiceFee within that. That scales; as new properties are added, the API has to change in the method you're describing.
As to the plural versus the singular, the author's examples give it away: to get the collection, you use plural; but then tacking on an id gives you companies/xxx, which returns a single company and seems clumsy.
I suspect the answer is just pick one and be consistent. I guess I prefer the pluralized version slightly, because it's more like this is a search API: get me all companies which qualify under the provided parameters (or lack thereof). I might even argue that companies/XXX should return a collection, even though we certainly expect only one to qualify, because it is a search.
But my lack of experience in this area probably means I'm filtering through the wrong lens.
|
|
|
|
|
|
Singular vs Plural is todays Tabs vs Spaces war. Both are correct for different reasons. I (we) tend to stay with singular unless there is a compelling reason to go plural. Primarily due to how some words pluralize (Person vs People).
This was an extremely lightweight article. The problem set is broader. Like, you have /populace endpoint. Do you return 300 million results or paginate the results? You need to incorporate security aspects. Do you have access to ALL the /populace (as a federal agency), or only some (as a state/province agency)? Even then, do you have access to all the data within a populace resource or only a limited set?
The problem I often see is thinking of the REST API like a programming API. It is not. If you go that way, you are building a RPC, and will have scaling issues at some point. You have to step back and really think resource. getServiceFee is communicative, but so is GET /serviceFee. But /serviceFee is not a "resource". It is part of a larger resource. Depending on access rights, it might be one of only a few elements available in the returned resource.
A better, simplified article is https://dzone.com/articles/5-basic-rest-api-design-guidelines[^]. It covers some of these points. A better collection of articles is https://dzone.com/articles/rest-api-best-practices-with-design-examples-from[^]. Sticking to these best practices helps open up some other frameworks to assist in building and documenting your API.
Bottom line, good REST is not simple or easy. It takes a lot of up front effort and then discipline to implement well. Even with that said, I (we) still got it wrong multiple times. Just less disasterously.
The cure to boredom is curiosity. There is no cure for curiosity. -- Dorothy Parker
modified 24-Dec-19 13:05pm.
|
|
|
|
|
Not only did tomales randomly get delivered to us last night (it happens), I finished Parsley in record time, and it is COOL tech, if wildly underappreciated.
Slang is so neat. I totally wanted to build a parser generator with code in the grammars that could work in any final language. It's here.
I love that it's working in the wild.
Next I may add backtracking support. If that works maybe I'll try to rebuild Slang's parser with it.
I'm just tickled. So much winning today.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
|
Today is as devoid of thermal excitation as the dextro-mamamry of a female necromancer. *
* I may have Leslied myself - but the day started at about -10C and windy with serious gusts off the ocean @ roughly 60-65 k/h
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
You forgot the enormous copper and zinc alloy lingerie.
|
|
|
|
|
I have to do so much processing to the codedom just to get VB to choke it down.
Why? The language is STUPID. That's why. There's no more succinct and accurate way to put it.
The grammar is stupid.
The runtime is stupid.
The language overall, is stupid.
You have two different equality operators you have to use depending on whether you're comparing reference types or value types. Because of that I have to visit every damned == and != in the tree, do type resolution on both sides of the expression (slow) and then based on that determine whether I should say "=" or "is"
Stupid.
You have to explicitly name your public implementation types for a method. So if i want to implement IEnumerator<t>.Current I have to also have Implements IEnumerable(of T)
This means for every public method you declare i have to go through all the base types of its declaring class, resolving each one (slow) to see if it matches the method signature (slow) of the declared method, so i can add Implements.
Stupid.
And don't get me started on the bugs in the VB codedom
It has taken me 2 hours just to fix all that crap
 Angry honey.
/rant
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: You have two different equality operators you have to use depending on whether you're comparing reference types or value types.
Not quite.
You use Is to compare for reference equality, and = to use the overloaded equality operator. But unlike C#, VB.NET won't fall back to using reference equality if the equality operator hasn't been overloaded.
Reference type vs value type is irrelevant, other than the fact that reference equality for value types will always be False.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
That's not what the compiler told me but okay. I don't trust it either.
Anyway, I'm doing ValueType checks now and it works.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
|
Sure, but the example you gave has no way to compare equality.
The closest thing you could do would be like Equals() or ReferenceEquals() at that point, and honestly i'm not sure how those will behave exactly on such a struct though i imagine ReferenceEquals() ends up comparing the stack pointers or something. I think Equals() would just forward basically to ReferenceEquals() in that case.
The other possibility is equals does a memberwise compare. That's about 50/50 likely but on such a struct they would always be equal since they have no fields. Hmmm
I'd have to research it all to be sure, but it gives me something to think about and look into.
Although it would be nice for VB to manufacture a way to do equality checks on such a structure, it's not very useful in practice. I wonder if i don't mind breaking in that case?
Considering that case uses = it gives you the opportunity to fix by overloading=
Unfortunately, you cannot overload operators in slang because CodeDOM won't render operator overloads.  but you can overload a class that it references the binary of.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: I wonder if i don't mind breaking in that case?
Probably a sensible option - C# won't let you use == on a struct which doesn't implement an equality operator either.
You're right about ReferenceEquals, which obviously wouldn't work for value types.
The default Equals implementation for a value type uses reflection to compare the value of all of the fields:
Reference Source[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
