Paneque's Technology Blog

Pages

Tuesday, May 16, 2017

Quite too often we see discussion about what is and what is not REST, some developers excitedly discuss about REST purity. However, does it actually matter? Do you need that level of "purity"? I personally think that it does not and will try to explain why, although I am already convinced that will fail on my attempt.

REST means REpresentational State Transfer, and while almost everybody will tell you that is not necessarily related to HTTP (and technically isn't), in reality, it is, and that's a fact. So when we apply it to our Web Services, we have our new REST APIs or RESTful APIs mixed with HTTP flavors.

Also consider that they do not conform a protocol, or a specification, is an architectural style. So, technically, they are a set of conventions and guidelines and not an actual set of unbreakable rules (like a protocol).

But they are great, RESTful, REST-like, almost RESTful APIs are all great. I have been writing and playing with APIs since around 2001, and came all the way from XML and SOAP (from the manual aspx, to asmx, to WCF) and then into JSON and REST , and I love them all. In fact, the only thing I don't like about REST is the people behind it trying to defend it so vehemently :) But there are some issues I am sure you might have encountered before:

Authentication: Purity zealots say that REST is pure and not HTTP-only, yet they use HTTP headers/cookies for authentication over a RESTful API.. wat?

Sometimes it becomes really hard to do it the REST-style (and RPC-style feels natural)

The typical verbs are not expressive enough for my API (all real life systems are more complex than CRUDy examples) and this kind of ties to #2.

Rule of thumb: Never stop when they tell you "it's not RESTful if..."

I found this online, no idea who the author is...

Lets shed some light over these 3 cases:

Case #1

Authentication against a RESTful service: there should be no discussion, your system architecture will make things easier or harder for you, and your decision can't be to put the "purity" of an architectural style over the consistency, completeness and correctness of your system. I have seen scenarios where cookies bring transparency, and others where a token over query string parameters are a better fit. Don't stop a solution because someone tells you "it's not RESTful if...".

Case #2

REST is definitely good, but it is not enough, because not everything is a resource. While the idea of exposing documents, files, resources (nouns) feels natural for a huge amount of cases, you will eventually find a situation where is not natural to expose something as a resource. "Resources" and "Processes" can be really complicated in the enterprise. Think about it, we are translating the logic from our object and methods/functions, to basically one "object", whose status can just be CRUDily accessed.

The REST-workaround to deal with this kind of issue is to "make it" a resource and then deal with its status. Let's say I have a process that can start/stop/pause/rotate/jump/recharge/sing (is my process, so the actions are whatever I decide :) ). One RESTful way to do this is to expose:

GET http://address/process/status

as a resource. We could GET the endpoint to query and then perform PUT with the new status every time:

{

started:true,

paused:false,

charging:false

//other fields

}

and then starting, or recharging would imply sending the status over via a POST.

POST http://address/process/status

This does not feel natural, passing back and forth the whole status of a process to start/stop "actions". It might be a RESTy way to do things, but certainly it does not help me on this case. What if we have 100 actions? RPC would be a better option here.

POST http://address/process/<start|stop|pause>

We can do things like:

POST http://address/process/jump?howhigh=20

and we could still query the status by calling in a RESTy way:

GET http://address/process/status.

There is no rule against combining them. Just go over you API and improve things as you go. Make things easier for you and the clients of your API. Blindly following guidelines for the sake of it, will yield no reward except suffering.

Having a well documented API is more important than breaking your head trying to conform to some guidelines.

Case #3

The verbs are not enough. Lets take the data structure of a stack and try to represent it in a REST API:

http://address/stack

would be my "stack" resource. The only way to modify a stack is by calling PUSH and POP operations, we don't have those verbs, but we can try and see if they fit our RESTful idea. I also need a COUNT, to know how many items are on the stack, and a PEEK, to read the one on the top without modifying the collection. Care to make this in a restful way?

GEThttp://address/stack

What should this do? To be RESTful, this should just return the whole stack, which is not very useful for what you typically want a stack (could apply same logic to a "queue"). And would be a terrible way to get the COUNT, and I really want the O(1) order of some operations over a stack.

POSThttp://address/stack

This could be our PUSH, sending an object to the top of the stack. What about POP?

DELETE http://address/stack

This makes no sense, because we are not deleting the stack itself. Then even something like /stack/top, would also be incorrect, since the element at that URI would be different after a delete, and finally because DELETE must be idempotent.

Then what? POST? We already used it. Once you reach this point, is better if we just go back RPC again.

GET http://address/stack/count (COUNT)

GET http://address/stack/top (PEEK)

POST http://address/stack/push (PUSH)

POST http://address/stack/pop (POP)

POP would "modify" the stack, so, a POST is the catch-all verb to use here. DELETE wont do it and PUT even less, they are both idempotent.

All these can be also applied to a queue, a circular queue or many other data structures. The verbs might not be enough to support your operations from a semantic point of view, and URIs might not be unequivocally representing a resource. /stack/top, its not a permanent URI for "the element" on the top, is the address of the "top of the stack", the element itself can and will vary over time.

I have a hard time trying to understand how RESTful could be a silver bullet without the ability to represent the most simple of structures. REST and CRUD-style is not enough for everything out there.

Tuesday, May 17, 2016

I just installed ASP.NET Core RC2 and was able to get it working from the command line, on some new basic tests projects. But when I tried to do it from Visual Studio I got the following error.

If I tried to run "dotnet" in a console opened from Visual Studio, I would get the same error. So the issue was that something was off for the VS configuration/environment.

After verifying that "dotnet" was able to run perfectly everywhere else I took into the task of comparing the environment variables (dichotomically, of course). One particular variable made the difference: "JUSTMOCK_INSTANCE=XXXXX", so that lead me to notice that JustMock was interfering with it somehow.

So, if you use JustMock just turn it off for RC2 projects. (No need to uninstall it, just disable the profiler)

After checking, double and triple checking again that the file was correct I went deeper and realized that "fs.readFileSync" was returning me the BOM for the UTF file at the beginning of the string. So we just need to strip it out.

Friday, December 04, 2015

Red blinking light? Check the power supply cord.

I just got my Microsoft Display Dock courtesy of MS after pre-ordering a Lumia 950XL. But after the first attempt I just got a red blinking light on the front and nothing more. The phone won't recognize it and the display connected would just go to sleep.

After playing with it a bit I realized the USB-C connector on the dock's power supply (identical to the "fast charger") was a bit loose. I then compared to the one that came with the 950XL and voilà! See the difference below.

Left: Adapter from the 950xl box | Right: Adapter from the Display Dock

Since it is shorter (manufacturer error? bad batch? who knows...) the adapter packaged with the Display Dock won't reach the connector properly. However, it will fit in and charge the 950XL perfectly. I think one of the reasons is the thick casing in the Microsoft Display Dock. Check it out.

The case is sturdy and thick.

So if you happen to have a Microsoft Display Dock, then you already have a 950/950XL that most likely came with a "fast charger" (why else would you get the accessory?). You can either switch them or return the dock to Microsoft for a replacement.

However the chargers are identical and you can also fast charge while connected to the dock.

Thursday, October 08, 2015

The last Microsoft event on October 6 showed a few surprises, let me explain you why this is impressive and why I think the new Nadella direction at MS is different. Iris Scanner, Liquid Cooling, Continuum...

A new Surface 4 tablet with Liquid Cooling
The new Surface 4 was a really good upgrade, and a real big one. More resolution in the same size, up to 16GB of RAM and 1TB of HDD and Liquid Cooling. All that packaged in a device as think as this, only 8.5mm of depth.

Check how the cooling works.

New phones with Continuum and Liquid Cooling

I know Windows only have 3% of the market on phones, and that's a bummer because we don't get to have all the apps. But now the new phones have continuum, a feature that allows using a phone as a full size computer. They also manage to get liquid cooling into a handheld device. That's a good direction. Let's just hope this new direction combined with universal apps will get more developers into the boat.

A new Surface Book.

Think got even crazier when MS announced this product, I think is safe to say that nobody saw it coming. A new powerful laptop hybrid (although expensive) and a crazy beautiful product. Looks like Microsoft is finally putting good design in combination with good specs in an effort to gain the consumer market.

That's impressive, right?

A new line of products, beautiful and powerful. New technologies like continuum, iris scanner and liquid cooling in devices so thin and small. New redesigned products like the new Band or the new Pen for Surface. This is a new MS, way different than the one that created the Zune.

PS: if you reading this from CodeProject then the CP crawler is still buggy and pulling posts without the CodeProject tag.

Friday, October 02, 2015

While using Visual Studio 2015 to edit and android layout file (axml) I got this error:

The installed Android SDK is too old. Version 24.3.4 or newer is required

The number version might be different in your case. Here are a few possible causes for the error:

1) You actually need to upgrade your Android SDK.

2) You have the wrong path for the Android SDK installation on Visual Studio. (change it on Tools->Options->Xamarin)

3) Mixed Xamarin extensions (this was my case)

After reinstalling the Android SDK and checking the everything was fine on that part I went to check on Visual Studio extensions (Tools->Extensions and Updates). It turns out that I caused a mix up of versions, since I already had Xamarin and Visual Studio 2013 side by side. and now 2015 had another one, my Visual Studio 2015 ended up with 2 extensions for Xamarin. Disabling one of them solved the problem and the designer was working again.

The one that I disabled was titled "Get Xamarin" and I kept the one that shows in the image. Unfortunately I uninstalled the bad extension before taking a screenshot.

Now you might not experience this problem if you have VS2015 in a clean install, but my computer does not have a clean install since 2011. Good luck!

Monday, February 23, 2015

It is a big deal, and by no means I would defend them; I don't think anyone can. They did a cheap and horrible thing by installing a piece of adware junk, that not only was used to monetize on the buyers, it is also a major security breach. Many people are still upset at lenovo and blaming everything on the "chinese government" and talking about all sorts of conspiracies.

But I don't want to talk about who did it or why, as I was reading about all this, I just could not stop wondering: are they the only ones? Of course not.

The Gemalto hack

But did you know about the Gemalto SIM card hack? A massive sim card hack that allegedly allows US and UK spies access to billions of phones. The Gemalto hack quoted here from PC World:

"Gemalto, based in the Netherlands, produces about 2 billion SIM cards a year. About 450 mobile carriers, including AT&T, T-Mobile, Verizon Wireless and Sprint, use the company’s SIM cards.

With the compromised encryption keys, the surveillance agencies would be able to monitor mobile communications without the approval of the carriers or foreign governments, The Intercept story said. The encryption keys would allow the agencies to intercept mobile traffic without court-ordered warrants or wiretaps, the story said."

The supercookies

Also Verizon and AT&T got involved into some pretty high level user tracking, using something called "supercookies". Basically they would be able to track all internet usage by users, no matter if they were using private navigation or incognito modes.

So this is not a new thing, big companies and governments placing adware and/or tracking us while compromising our security? It is not new.

What can you do?

You can use a Tor browser for better privacy online, VPNs are also a good option. And the next the time you buy a new PC at the Home Depot, do a clean install and put everything yourself.