Web API is a very very different beast from WCF and ASMX. I know some folks have been used to the way with WCF and ASMX that you create "Messages" or "DTO's" and that a lot of the time I would see folks thinking that they should return a lot of data with state. and the way that the old services worked with the data and the http stack there was the question of how much data to send and what data to relate in one return.
Now along comes the whole move to REST and JSON and the new world of the WebAPI....
First thing is that WebAPI has no clue about the database and the data you send should not try to carry over a lot of the database .... not a record, not a DTO and not statefull other than what the data in-of-itself has for state.
WebAPI should be thought of as working with JSON documents if you are doing data.
but even then you can have a Web API that can return images, pdf files or any other kind of data you need to do your job. Some folks might cry at that idea as they might want some very REST full stuff that conforms to some standard... well if the standard works good use it. but really WebAPI is about HTTP and what does HTTP do ?
returns a document.
think about that for a minute.... a document. not an "OBJECT" not a "Message" not a "Record"....
SO it can be a pdf file, a jpeg file, a video, a song or a JSON file. all works the same in the end.
Well I will have to stop for now but I will continue this in my next post...
three words that start with "A" that come up in most talks about logins and such:
Now each has a place and we need all of them.
short nicknames like "OAuth" lead to a lot of confusion, I think the term was a poor choice but I can also see how they got there.
OAuth is "Authorization" not "Authentication" the first thing that a new developer learns about it.
I think this got started as we have multiple companies that each want to keep data on "who you are" and social net works want to be well "Social" so they tend to want to share or exchange some of that "who are you" stuff.... but they and the applications that build on them want to keep other data on "What can you do" ok I get that bit...
but what happened to the "Authentication" part? I can't know who you are or what I will let you do unless we can prove that you are who you say you are....
after that we start talking about Open ID and all kind of other stuff...
this might all be good if you are the next facebook but what if you are just building an app and your boss said that we need OAuth cuz he heard it was the way to go?
might be that we need to have a talk about how that new buzzword is the wrong thing for the job at hand... not a fun talk to have if you just got hired!
This is where the story starts... More to come.
I do not know if I am 100% in agreement but this is interesting and not far from the truth I think:
I am starting to work on a longer set of posts on this but here is a first pass:
TLDR: developers want a simple to install and manage solution for handling user logins, api call permissions and mapping roles. Oauth and Open ID are standards that seem to be the result of committee that had no input from a real world developer trying to make something that works. the number of confusing terms used and different meanings and different "flows" and "Clients" and "Token Types" creates a jungle of things for the developer who just wants to get his or her job done.
Later I will compare this with an OLD thing called "RADIUS" that was used in the days of Dialup and how it covered a lot but was very simple to use. then I want to talk about what I think most of us want and is there anything out there that is a better fit.
Welcome to my new blog site.
Sorry but I have not yet got everything setup so give it a day or two....