I have noticed that I have given too much trust to API’s. They are so easy and 99% of the time they do what I want. The biggest issue I have come to realize is they hide too much sometimes. What can API’s do to help foster the original intent, say if you need to diagnosis something further?
So, I knew about the OSI model before making lots of web sites and services. There are 7 layers and they work like so:
1)Application (i.e HTTP) 2)Presentation 3)Session (i.e SSL) 4)Transport (i.e TCP, UDP) 5)Network (i.e IP) 6)Data Link 7)Physical
I know these layers pretty well. And HTTP, I thought was no exception. You can telnet into google’s web server and give it the ol’ “Get http://www.google.com” and get back a 200 OK and the page that Google servers. But there is a huge disconnect between Asp.Net that has made me not understand this in the past. The disconnect is that when I ask for the resource in telnet, my application’s debugger automatically ends up at the break point inside of the controller. Wait, how did it get there?
There is a request object, but it is hidden in the this variable. The worst part is, if you don’t know what you are looking for, because you have used the framework all your life, you might miss out on this. While you might say, well Jorden, just read the specification that Microsoft has on their site, I do have to compare it to other frameworks. If you look at Node.js, the way it abstracts request and response objects is a better way. How? The request and response objects are parameters in your function for express and other http web servers, from node! The request and response objects are right there in the function signature, and are not hidden in a this variable. Do you need to know what function is called for a route or resource? The route is right there smacking you in the face in node.js, as it is part of the application setup.
I do think that ASP.net MVC is a great framework, but it is still plagued by not exposing the right abstractions to it’s developers. If they would have smacked users in the face with the, route, pipeline, request and response objects, then people would have embraced the platform more so. I know, I should research every API I use before I use it. This is something Joel on Software suggests, but I feel API developers could spend the time to study the framework and know what is good and bad for the user’s to know.
I think now ASP.net MVC is moving to have routes in the controllers and provide the better visibility, up front, to the developer. This gives us more of a chance at learning the important things about the internet, and hide the other parts for us. Like building a response and request object.