“Dependency Injection” (DI), also more cryptically known as “Inversion of Control” (IoC), can be used as a technique for encouraging this loose coupling.
John Munsch explains it like this:
When you go and get things out of the refrigerator for yourself, you can cause problems. You might leave the door open, you might get something Mommy or Daddy doesn’t want you to have. You might even be looking for something we don’t even have or which has expired.
What you should be doing is stating a need, “I need something to drink with lunch,” and then we will make sure you have something when you sit down to eat.
In designing an object-oriented application, a major tenet of design is “loose coupling”. Objects should only have as many dependencies as is needed to do their job – and the dependencies should be few.
There are three primary approaches to implementing DI:
- Constructor injection
- Setter injection (also called Property injection)
- Method injection
Constructor injection uses parameters to inject dependencies. In setter injection, you use setter methods to inject the object’s dependencies. Finally, in interface-based injection, you design an interface to inject dependencies.
Continue reading “Dev Patterns – Dependency Injection (aka Inversion of Control)”
In his talk on Some REST Design Patterns (and Anti-Patterns), Cesare Pautasso explains, “REST architectural style is simple to define, but understanding how to apply it to design concrete REST services in support of SOA can be more complex.”
Several SOA Design Patterns:
- Uniform Contract
- Endpoint Redirection
- Content Negotiation
- Idempotent Capability
In this post, you will learn the design methodology, walk through a step by step scenario where the client and server trade information to perform a set of actions, and you will learn more about the SOA design patterns.
Continue reading “CloudDays™ Quick Start – Introduction to Design Methodology, Patterns for REST”
In the previous posts, you learned how to design your RESTful API. In this post, you will learn about the best practices of versioning, analytics, how to set up your API root, what your consumers are expecting for results, why and how filtering should work, and caching.
Continue reading “CloudDays™ Quick Start – Designing Your RESTful API Part 3: Best Practices”
In the post Designing Your RESTful API Part 1: The Nouns, you learned the importance of resources, request headers, and the request body when you defined your RESTful API. In this post, you will learn about the five or so request verbs and what is send back to the client in the response body and the response status code.
Continue reading “CloudDays™ Quick Start – Designing Your RESTful API Part 2: The Verbs, Responses, Response Status Codes”
Everything is a resource in REST. As you learned in Choosing Between RESTful Web Service, SOAP, Representational State Transfer (REST) is an architecture style or design pattern for creating web services which allow anything connected to a network to something else on the network using Hypertext Transfer Protocol (HTTP).
In this post, you will learn the how to define your resource identifier. In the following post, you will learn how to use the HTTP verbs and response codes. And along the way you will learn many of the principles of a good RESTful API.
Let me second what As Thomas Hunter II writes:
The easier your API is to consume, the more people that will consume it.
Continue reading “CloudDays™ Quick Start – Designing Your RESTful API Part 1: The Nouns”