2019 – A year of Blogs

A year of Blogs ~ What we learned and looking ahead.

In 2019 the ECI marketing department rebuilt from the ground up and took on new initiatives in order to better serve our community, clients and employees.

We knew we had in our arsenal of talent some of the most successful and resourceful consultants in the industry, so with their help and a dedicated team of employees supporting their activities, ECI was able to publish weekly blogs around software development, project management and enterprise architecture.

Our most successful blogs of 2019 were:

Following your comments, activity we have learned what would be the areas of most interest for members of our community.

We have a variety of new blogs to be published from our team through out 2020, we are planning to be even more active and use the incredibly talented team we have to put out quality content on the regular.

You can follow our activity by signing up to our monthly newsletter on Estradaci.com

or by following us on TwitterFacebook, Linkedin and Medium!

We really look forward to hearing from you and cherish the time you take to comment and interact with our content.

ECI 2019 Year of Events Review

This year we TRAVELLED!

2019 was a year of revamping our marketing activity here at ECI! We rapidly increased our presence across events in North America. As the year went on, we met some of the most influential employees, CIO’s and contractors across Canada and the United States.



Where We Went

In 2019 we participated in many events across the United States and Canada, we focused our attention to the events where we could connect with influential people, learn and have an opportunity to showcase our incredible accomplishments.

  • State of Technology — California, USA
  • Azure Technical User Group — British Columbia, Canada
  • DotNet Technical User Group — British Columbia, Canada
  • CTOBC — Nevada, USA
  • Tableau Technical Group — California, USA
  • Tableau Technical Group — British Columbia, Canada
  • Oracle Technical Group — British Columbia, Canada
  • Data Science Expo — British Columbia, Canada
  • Microsoft Power BI — British Columbia, Canada
  • Seattle Reverse Vendor Trade Show — Washington, USA
  • Union of BC Municipalities — British Columbia, Canada


What We Learned

The year 2019 was a multi faceted year for ECI activities, it was the year the company entered and started operations in British Columbia, by setting up an office and putting together a team working out of Vancouver. Members of ECI attended and connected with many industry and government professionals to showcase and network around the incredible accomplishments of ECI.
Our consultants and developers learned about the state of technology in governments across the west coast of the United States and Canada.
Representation is key! As a part of ECI marketing activity we want to make it easy for governments and organizations to find us, speak to us and ask us questions. We know we have a strong arsenal of experience and contracts under our portfolio that contain years and years of valuable knowledge for individuals and organizations looking to expand and renew their public services.



Where We Will Be 2020

2019 was a busy year… 2020 will be busier, ECI Consultants and Executives will be attending multiple conferences, trade shows and government events to share our knowledge and meet the great people who work hard to make life better for the people of Canada and the United States.

Some of the events ECI members may be attending in 2020: 

  • TDWI — Las Vegas, Nevada
  • ConnectBC — Victoria, BC
  • Transit Initiatives and Communities Workshop — Sacramento, California
  • Excellence in Transportation Awards — Los Angeles, California
  • BC Transit Workshop 2020 — Vancouver, BC
  • Digital Government Summit — Sacramento, California
  • CES Government — Las Vegas — Nevada
  • Washington State Regional Contracting Forum — Seattle, Washington
  • BC Tech Impact Awards — Vancouver, Canada
  • BC Tech Summit — Vancouver, Canada
  • California CIO Awards — Sacramento, California

We look forward to seeing you & hearing from you.

If you know of an event or want to see us at one, make sure to send us an email, message or tweet at us.

RESTful API Designing Guidelines

Your introduction for everything REST and how to understand it.

What is REST?

Representational state transfer (REST) is a software architectural style that defines a set of constraints to
be used for creating Web services. Web services that conform to the REST architectural style, called
RESTful Web services, provide interoperability between computer systems on the Internet.


The following are the most important terms related to REST APIs:

Resource is an object or representation of something, which has some associated data with it and
can be set methods to operate on it.
E.G Company

Collections are a set of resources.
E.G Companies is the collection of the Company Resource.

URL (Uniform Resource Locator) is a path through which a resource can be located and actions can
be performed on it.

API Endpoint
In simple terms, an API endpoint is the point of entry in a communication channel where two systems are
interacting. It refers to a touch point of communication between an API and the server.
The location where the API sends a request and where the response emanates is what is known as an

API vs Endpoint
An API refers to a set of protocols and tools that allow interaction between two different applications. It is a technique that enables third-party vendors to write programs that can easily interface with each other. On the other hand, an endpoint is the place of interaction between applications. API refers to the whole set of protocols that allows communication between two systems while an endpoint is a URL that enables the API to gain access to resources on a server.

Web Api Endpoint Naming Convention

Methods Naming Convention
In OOP methods are named with verbs to make it easier to identify what operation that method will
perform, for example the method GetEmployees(int departmentID) will return all the employees that
belongs to a department.

Should we use the same naming convention when designing web Api’s endpoints?
The answer is NO.
Web Api endpoints must be names with NOUNS instead of verbs and it should contain the plural form of
the Resource the api will perform operations on.

Example: https://www.estradaci.com/apis/v1/Employees

If the URL can’t contain verbs, how do we know which action will be performed?
HTTP Verbs will be responsible for telling which action the WEB API should perform.
Let’s look at the most used HTTP Verbs used while creating WEB APIs.


Use GET requests to retrieve resource representation/information only – and not to modify it in any
way. As GET requests do not change the state of the resource, these are said to be safe methods.
Additionally, GET APIs should be idempotent, which means that making multiple identical requests must
produce the same result every time until another API (POST or PUT) has changed the state of the
resource on the server.

 GET https://www.estradaci.com/apis/v1/Employees
 GET https://www.estradaci.com/apis/v1/Employees/1
 GET https://www.estradaci.com/apis/v1/Employees?name=Jeff
All the endpoints above will fetch employees but using different inputs to query the employees.

Use POST APIs to create new subordinate resources, e.g. a file is subordinate to a directory containing it
or a row is subordinate to a database table. Talking strictly in terms of REST, POST methods are used to
create a new resource into the collection of resources.
 POST https://www.estradaci.com/apis/v1/Employees
 POST https://www.estradaci.com/apis/v1/Employees/Address

Both endpoints above will insert data in the database, the first one will create a new employee and the
second one will create an address for an employee.

Use PUT APIs primarily to update existing resource (if the resource does not exist then API may decide to
create a new resource or not). If a new resource has been created by the PUT API, the origin server
MUST inform the user agent via the HTTP response code 201 (Created) response and if an existing
resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to
indicate successful completion of the request.
 PUT https://www.estradaci.com/apis/v1/Employees
 PUT https://www.estradaci.com/apis/v1/Employees/Address

Both endpoints above will update data in the database, the first one will update an employee and the
second one will update the employee`s address.

As the name applies, DELETE APIs are used to delete resources (identified by the Request-URI).
 DELETE https://www.estradaci.com/apis/v1/Employees
 DELETE https://www.estradaci.com/apis/v1/Employees/Address

Both endpoints above will delete data from the database, the first one will delete an employee and the
second one will delete the employee`s address.
As we can see the same URL can perform different actions when requested with different HTTP Verbs.

For example the https://www.estradaci.com/apis/v1/Employees can Get, Create, Update and Delete
employees based on the HTTP Verb used.

HTTP response status codes

Sometimes when the client sends a request to the server it expects a response indicating the result of the
operation. it’s a good practice to return coherent status codes to make it easy to the client understand what
happened when the request is processed.
HTTP defines standard status codes that can be used to convey the results of a client’s request. The
status codes are divided into the five categories presented below.


1xx: Informational Communicates transfer protocol-level information.

2xx: Success Indicates that the client’s request was accepted successfully.

3xx: Redirection Indicates that the client must take some additional action in order to complete their request.

4xx: Client Error This category of error status codes points the finger at clients.

5xx: Server Error The server takes responsibility for these error status codes.

Check below the description of the most used Status Codes used when creating a web api.

For a complete list of the HTTP Status Codes check https://docs.microsoft.com/en-

200 (OK)
It indicates that the REST API successfully carried out whatever action the client requested, and that no
more specific code in the 2xx series is appropriate.

201 (Created)
A REST API responds with the 201 status code whenever a resource is created inside a collection. There
may also be times when a new resource is created as a result of some controller action, in which case
201 would also be an appropriate response.

204 (No Content)
The 204 status code is usually sent out in response to a PUT, POST, or DELETE request when the REST
API declines to send back any status message or representation in the response message’s body.
An API may also send 204 in conjunction with a GET request to indicate that the requested resource
exists, but has no state representation to include in the body.

304 (Not Modified)
This status code is similar to 204 (“No Content”) in that the response body must be empty. The key
distinction is that 204 is used when there is nothing to send in the body, whereas 304 is used when the
resource has not been modified since the version specified by the request headers If-Modified-Since or

400 (Bad Request)
400 is the generic client-side error status, used when no other 4xx error code is appropriate. Errors can
be like malformed request syntax, invalid request message parameters, or deceptive request routing
The client SHOULD NOT repeat the request without modifications.

401 (Unauthorized)
A 401 error response indicates that the client tried to operate on a protected resource without providing
the proper authorization. It may have provided the wrong credentials or none at all.

404 (Not Found)
The 404 error status code indicates that the REST API can’t map the client’s URI to a resource but may
be available in the future. Subsequent requests by the client are permissible.

500 (Internal Server Error)
500 is the generic REST API error response. Most web frameworks automatically respond with this
response status code whenever they execute some request handler code that raises an exception.

Content Negotiation

When sending a request to an API we need to tell the server what is the type of the data we are sending
and the server is responsible to tell the client the same.

At server side, an incoming request may have an entity attached to it. To determine it’s type, server
uses the HTTP request header Content-Type.

Some common examples of content types are :“text/plain”, “application/xml”, “text/html”, “application/json”, “image/gif”, and “image/jpeg”.

Content-Type: application/json
Similarly, to determine what type of representation is desired at client side, HTTP header ACCEPT is
used. It will have one of the values as mentioned for Content-Type above.
Accept: application/json

The most used content-type used by APIS to represent the object the is being sent to the server or
returned to the client is JSON, make sure to use the camelCase naming convention when using JSON.

API Versioning
One of the most important things in WEB API development is the versioning.
WEB APIs must be well versioned in order to prevent the clients that are consuming it to break.

When a Break Change is made to an existing WEB API, instead of modifying the existing one we must
create a new version of it.

For example:
Several changes are required to be made on the WEB API
https://www.estradaci.com/apis/v1/Employees and these changes may lead the consumers to break
their integrations.
Instead of simply applying the changes to this API we need to create a new version of the api, E.G
This will prevent the clients that are consuming the V1 to break and will give them the time and
flexibility to migrate their calls to the V2.

REST vs. gRPC – The Battle Over Service Orientation

Rest Vs. gRPC

Services are a common talk between developers and companies that are in the process of implementing software; they are an important piece in any project architecture as they separate layers of functionality and offer the flexibility of implementing different levels of security in between layers. Their implementation can vary from serving data from the database servers, sending messages to other servers, and much more.

In .NET technologies there used to exist an entire framework dedicated to services and Windows Communication Foundation, this collection of tools would help set up services in a variety of protocols. On the downside, they were closely coupled with .NET, making the configuration of services more complex than some of the most popular options of its time.

Then came REST, a new portable way of communicating clients and servers via TCP, making them accessible over the internet. Most of the big web sites implement REST APIs to provide information to the outside world (such as Google, Twitter, LinkedIn, etc.). This model is based on Request-Response model that will return a text-based response (JSON, XML, HTML), currently the standard is JSON (JavaScript Object Notation). This is a flexible way to work with objects without depending on the platform.

The Problem…

The problem with JSON comes when you have a high demand application (server or client) that will make a large amount of request/responses. If you have to serialize/deserialize the objects to your native types, it will add an extra conversion overhead. If you are not having a outword facing application, you mostly have the same technologies applied in both sides of the communication, meaning that the service will have to take the response object from C#, serialize it to JSON and send it back to the client. Then the client will take the response JSON and deserialize back to your C# object. This is by no means hard to achieve, but the processing time may be impacted by the workload of your application.

There is a solution!

To solve this, we have RPC (Remote Procedure Call). This communication is based on Protocol Buffers, a mechanism to serialize data (the data is serialized in raw format). It offers all the main functionalities that REST does, with the added option for bidirectional streams that allow the client and server to communicate asynchronously that result in faster times. The configuration steps to get a gRPC service may seem a little more complex and limited than REST (Protocol Buffers currently supports generated code in C++, Go, Java, Phyton, Ruby and C#), but the benefit of faster performance may compensate.

In conclusion.

Current implementation of services using gRPC came with the adoption of Cloud computing and microservices with high performance demand. So, if you are planning create or enhance a service take a look at the past first, then present technologies and the future of your implementation in order to make the correct call. In conclusion, REST is still the most simple and portable solution if you don’t have an issue with communication performance.

If you want to know more about gRPC go to https://grpc.io/docs/guides/

Happy 5 Year Anniversary Trijo!

November is a big month for ECI and it’s members;

We are happy to announce the 5 year anniversary of Trijo George at Estrada Consulting Inc.

Estrada Consulting Inc. is proud to have some of the greatest and most dedicated talent around as a part of its team. We know and appreciate the hard work and dedication that goes in to pulling off such a successful record of work across the industry.

We understand that you have a choice and we congratulate ourselves on having you a part of our team.

Thank you for bringing your best to help us achieve success across North America year after year.

From the ECI Family, we would like to congratulate you, and thank you on your 5 years anniversary of being a part of our story.

Congratulations on achieving this anniversary with us! We know you have worked hard for this accomplishment and we truly appreciate your dedication.

1 2 3 6