jump to navigation

$ (dollar) prefix for angularJS January 17, 2014

Posted by Terry.Cho in Uncategorized.
Tags: , ,
add a comment

$ prefix in angularJS
It is for angularJS predefined service only.
It is just a naming convention from the below snippet http://docs.angularjs.org/tutorial/step_05

‘$’ Prefix Naming Convention
You can create your own services, and in fact we will do exactly that in step 11. As a naming convention, angular’s built-in services, Scope methods and a few other angular APIs have a ‘$’ prefix in front of the name. Don’t use a ‘$’ prefix when naming your services and models, in order to avoid any possible naming collisions.

Advertisements

Concept of AngularJS Service & Controller (Note) January 17, 2014

Posted by Terry.Cho in Uncategorized.
Tags: , , ,
add a comment

The service is some kinds of library which can be injected by using DI.
The service is singleton and binded to module
Angular injects dependencies using “constructor” injection.
and when it tried to use the service.

The service is injected as a parameter in constructior or it can be injected by using injection annotation ($inject)
The service can be injected to other services or controller

* Service dependency injection to Controller
angular.module(‘invoice2’, [‘finance2’])
.controller(‘InvoiceController’, [‘currencyConverter’, function(currencyConverter) {
The controller import module named ‘finance2’.
In Invoice Controller it tried to use ‘currencyConverter’, so the service is refered by the controller like “controller(‘InvoiceController’, [‘currencyConverter’, ”
and the try to use currencyConverter the parameter also has been passed to constructor function like this “function(currencyConverter)”

* Controller Parameter
[‘servicename’,’servicename’….,function(servicename,servicename)]
the ‘servicename’ is the service name will be injected to the controller
You can also alias service name in function like
[‘$scope’, ‘angularFire’, function(skop, af) {}]
the service $scope will be mapped to skop and angularFire will be mapped to af.
But is is not recommended to change the service name.
※ reference http://stackoverflow.com/questions/19238191/understanding-angular-js-controller-parameters

Advanced REST November 13, 2009

Posted by Terry.Cho in Uncategorized.
Tags: ,
add a comment

The basic concepts of REST were covered in Chapter 1. Still REST can be implemented in a more advanced version if utilizing the merits of HTTP.I would like to explain about the advanced REST in this Chapter with an example by using http://www.infoq.com/articles/subbu-allamaraju-rest .Let’s assume that the business scenario is making an account transfer from a bank.

1. Implementing an account transfer scenario through internet banking

STEP 1. Log-in to the internet banking system.

STEP 2. View the list of accounts of the relevant user through user ID.

http://bank.org/accounts?findby=7t676323a

200 OK
Content-Type: application/xml;charset=UTF-8
<accounts xmlns=”urn:org:bank:accounts”>
<account>
<id>AZA12093</id>
<customer-id>7t676323a</customer-id>
<balance currency=”USD”>993.95</balance>
</account>
<account>
<id>ADK31242</id>
<customer-id>7t676323a</customer-id>
<balance currency=”USD”>534.62</balance>
</account>
</accounts>

Regarding user ID 7t76323a, the two accounts of AZA12093 and ADK31242 will be returned along with the balance in those accounts. As the user made inquiry on each account number, the details of each account will be http://bank.org/account/AZA12093

http://bank.org/account/ADK31242

STEP 3. To see the business scenario of making account transfer,

POST /transfers
Host: bank.org
Content-Type: application/xml;charset=UTF-8

<transfer xmlns=”urn:org:bank:accounts”>
<from>account:AZA12093</from>
<to>account:ADK31242</to>
<amount currency=”USD”>100</amount>
<note>RESTing</note>
</transfer>

100 USD is transferred from AZA12093 to ADK31242 through HTTP post. Upon a successful account transfer, the following result value will be returned.

201 Created
Content-Type: application/xml;charset=UTF-8
<transfer xmlns=”urn:org:bank:accounts”>
<from>account:AZA12093</from>
<to>account:ADK31242</to>
<id>transfer:XTA8763</id>
<amount currency=”USD”>100</amount>
<note>RESTing</note>
</transfer>

In this case, take careful note that the return value is not HTTP 200 but HTTP 201. As the account transfer takes place not immediately but afterwards through async, HTTP 201 Created (meaning that the account transfer request has been received) as well as Transfer Application No XTA8763 are returned.

STEP 4. To check the account transfer details after one day,

http://bank.org/check/XTA8763
GET /check/XTA8763
Host: bank.org
200 OK
Content-Type: application/xml;charset=UTF-8
<status xmlns=”urn:org:bank:accounts”>
<code>01</code>
<message xml:lang=”en”>Pending</message>
</status>

The relevant account transfer request is indicated in a pending status.

2. Implementing an account transfer scenario through internet banking using the advanced REST

At a glance, it seems like an advanced and well-developed REST, but actually cannot be called as a successful architecture with the real merits of REST incorporated.

REST should have the following features:

First, REST should be able to identify the resource by using URL.

Second, REST should be able to represent various approaches toward the resource by using many functions of the HTTP protocol – especially the HTTP Header. For example, the Message Exchange Pattern of Sync/Async type (Call Back using the correlation ID) as well as the Meta Data like ‘Last Update Time’ to use web cache should be defined in the HTTP Header. Also the input and output data format should be defined based on the contents type.

Third, REST should be able to represent the relation between resources or the status information of the current resource through a link.

Based on such features of REST, let’s develop the previously-created account transfer scenario again.

STEP 1. Log-in to the internet banking system.

STEP 2. View the list of accounts of the relevant user through user ID.

200 OK
Content-Type: application/vnd.bank.org.account+xml;charset=UTF-8
<accounts xmlns=”urn:org:bank:accounts”>
<account>
<id>AZA12093</id>
<link href=”http://bank.org/account/AZA12093&#8243; rel=”self”/>
<link rel=”http://bank.org/rel/transfer edit”  type=”application/vnd.bank.org.transfer+xml”  href=”http://bank.org/transfers”/&gt;
<link rel=”http://bank.org/rel/customer&#8221;
type=”application/vnd.bank.org.customer+xml”
href=”http://bank.org/customer/7t676323a”/&gt;
<balance currency=”USD”>993.95</balance>
</account>
<account>
<id>ADK31242</id>
<link href=”http://bank.org/account/ADK31242&#8243; rel=”self”/>
<link rel=”http://bank.org/rel/transfer&#8221;
type=”application/vnd.bank.org.transfer+xml”
href=”http://bank.org/transfers”/&gt;
<link rel=”http://bank.org/rel/customer&#8221;
type=”application/vnd.bank.org.customer+xml”
href=”http://bank.org/customer/7t676323a”/&gt;
<balance currency=”USD”>534.62</balance>
</account>
</accounts>

As explained above, a slightly different type of return value will appear. What to check first is the content-type. : application/vnd.bank.org.account+xml; the return type of content-type will be returned. First, +xml mean that the format of this document is xml. vnd.bank.org.account defines the structure of returned data. (One of the weak points of REST – undefined data type – can be resolved by assigning an ID to the unique name of XML schedule used as an input or output)

Another change is that the LINK part has been added. This LINK indicates how the status of the current resource can change and what kind of URL can be used for status change. Also, it can indicate the relations with another relevant resource and define the data type, which is returned upon calling, as content-type. If the data type and the relation with another resource are defined in the returned message, user will be able to understand how to use and the relation of the resource without referring to a separately defined service. Therefore such feature of REST is called a ‘self-descriptive message’.

<account>
<id>ADK31242</id>
<link href=”http://bank.org/account/ADK31242&#8243; rel=”self” type=”application/vnd.bank.org.account+xml”/>
<link rel=”http://bank.org/rel/transfer&#8221;
type=”application/vnd.bank.org.transfer+xml”
href=”http://bank.org/transfers”/&gt;
<link rel=”http://bank.org/rel/customer&#8221;
type=”application/vnd.bank.org.customer+xml”
href=”http://bank.org/customer/7t676323a”/&gt;
<balance currency=”USD”>534.62</balance>

In this case, there are 3 types of changes: Self, http://bank.org/rel/transfer and http://bank.org/rel/customer

Firstly http://bank.org/rel/transfer, which is an account, defines the relation with a “transferable account”. To make account transfer, send through http://bank.org/transfers URL and the return value will become application/vnd.bank.org.transfer+xml.

Secondly self indicates a more detailed information of the account itself. It can be inquired through http://bank.org/account/ADK31242 and the returned data type will be application/vnd.bank.org.account+xml.

Thirdly http://bank.org/rel/customer indicates the client information. It can be inquired through http://bank.org/customer/7t676323a and the returned data type will be application/vnd.bank.org.customer+xml.

STEP 3. Execute account transfer.

Send the following data to the URL that has been returned from STEP 2.

POST /transfers
Host: bank.org
Content-Type: application/vnd.bank.org.transfer+xml;charset=UTF-8
<transfer xmlns=”urn:org:bank:accounts”>
<from>account:AZA12093</from>
<to>account:ADK31242</to>
<amount currency=”USD”>100</amount>
<note>RESTing</note>
</transfer>

The return value is as follows.

201 Created
Content-Type: application/vnd.bank.org.transfer+xml;charset=UTF-8
<transfer xmlns=”urn:org:bank:accounts”>
<link rel=”self” href=”http://bank.org/transfer/XTA8763″/&gt;
<link rel=”http://bank.org/rel/transfer/from”type=”application/vnd.bank.org.account+xml”href=”http://bank.org/account/AZA12093″/&gt;
<link rel=”http://bank.org/rel/transfer/to” type=”application/vnd.bank.org.account+xml” href=”http://bank.org/account/ADK31242″/&gt;
<link rel=”http://bank.org/rel/transfer/status” type=”application/vnd.bank.org.status+xml” href=”http://bank.org/check/XTA8763″/&gt;
<id>transfer:XTA8763</id>
<amount currency=”USD”>100</amount>
<note>RESTing</note>
</transfer>

STEP 4. Check the status of the account transfer progress.

The status of the account transfer progress can be checked by using http://bank.org/check/XTA8763 which has been returned from STEP 3.

Conclusion

From this article, I tried to focus on defining the data types by using the content-type of HTTP as well as the relations between resources by using a link. Yet I haven’t found the “perfect” standardized design even though there are many REST related articles that embrace similar philosophies.

Of course, as shown in the aforementioned examples, the in/out data format can be defined based on the content-type. Although the out (return) data format can be defined based on the defined types in the link, still the input aren’t defined. Also according to other designs, there are ways to define the data type by defining the URL of the real XML scheme in the URL of XML namespace.

From a protocol point of view, a link can be used by defining the relations between resources. This approach sounds preferable but actually can create various constraints during the actual implementation.

This article only presents a mere example of REST design in a more advanced version by utilizing HTTP more efficiently. However, more considerations are required for a more practical REST design.

=======

Comment

Please kindly consider that this article covering the advanced style of REST design is yet an uncompleted version and needs to be supplemented with more feedback. I will try to introduce the advanced style – especially regarding LINK and data type – with more details next time. In my following article, you will be able to learn about how REST is actually implemented in JAVA.

REST Architecture overview November 12, 2009

Posted by Terry.Cho in Uncategorized.
Tags: , , ,
1 comment so far

REST Architecture

REST was introduced in 2000 from a thesis written by Roy Fielding, one of the founders of web (HTTP). As the current architecture wasn’t able to make full use of the superiority of the original web design, the Representational Safe Transfer (REST) was introduced as a network-based architecture that could best utilize the merits of web.

Basics of REST

Simply put, REST is a HTTP URI + HTTP Method, which clearly states the target resource through URL and defines the operations of such relevant resource through Method.

Resource

One of the key features of REST is representing all resources as ‘Resource’. This Resource is expressed through HTTP URL. For example, a user named ‘bcho’ from a javastudy website can be expressed as http://www.javastudy.co.kr/users/bcho while a HP printing machine located at the 9th floor of a Gangnam office can be expressed as http://printers/localtion/seoul/kangnamgu/9f/hp. In this way, all resources can be expressed through HTTP URL.

Action

Then how are the operations of the relevant resource represented? In this case, HTTP Method is utilized.

*  In order to bring the member information of bcho from a javastudy website,
URI : http://www.javastudy.co.kr/users/bcho
Method : GET

* Also in order to create the relevant member,
URI : http://www.javastudy.co.kr/users/bcho
Method : POST
PayLoad
<payload>
<name>Cho Dae Hyup</name>
:
</payload>

*  In order to delete the relevant member,
URI : http://www.javastudy.co.kr/users/bcho
Method : DELETE

*  In order to change the information of the relevant member,
URI : http://www.javastudy.co.kr/users/bcho
Method : PUT
PayLoad
<payload>
<name>Cho Dae Hyup</name>
:
</payload>

* In other words, the 4 Methods from the HTTP Protocol define CRUD of the Resource.

HTTP Method Meaning
POST Create
GET Select
PUT Create or Update
DELETE Delete

Shortcomings of REST

However, there are several shortcomings such as the number of available Methods is only 4. For example, Methods like ‘send email’ or ‘log write’ cannot clearly be expressed through HTTP Method.

As the existing programming style has taken an operation-oriented approach centered on functions or Methods, those methods conflict with the resource-based approaches that REST embraces. The reason for REST being called as architecture rather than a simple protocol is that it can be appropriately applied to resources that have CRUD (ex. DBMS).

Then how can these shortcomings be resolved?

As a matter of fact, CRUD is not enough to express all operations. To express operations with control or functional features, HTTP/PUT or POST Method is used or a functional approach is required. For example, a ‘send mail’ operation can be changed into a meaning of ‘create a mail to send it to someone’ through HTTP/POSThttp://www.xxx./sendmail/to/{emailaddress}.

Still, there are cases that cannot change the meaning of the context.

In these cases, HTTP/PUT or URL is used to grant the meaning of control. The grade of user ID bcho can be changed through the following.

For example, http://www.xxx/users/bcho/upgrade

In fact, the most difficult challenge in designing a REST-based architecture is how to define this URL. One of the merits of REST is that it is quite easy to grasp the meanings through this URL or HTTP Method. Therefore, much effort is required in defining the URL.

Pros & Cons

Pros

The existing web infrastructure can be utilized in tact.

This is one of the largest advantages. As the existing HTTP is used as it is, there is no need to break a firewall when making a remote calling and the load balancer equipment like L4 can be used in tact.

The exciting thing is that the web cache can be used as it is. Because every resource is expressed uniquely through URL, it can be stored within the web cache and especially operations that are selective can be returned by this cache without going through actual business transactions. Such features are strongly beneficial from performance and resource utilization perspectives.

Easy

Compared with the web service, which encompasses so many cumbersome SPECs like WS*-I, WS Reliable Messaging, WS Transaction, REST doesn’t need a separate SPEC. Generally REST is called as a ‘Defactor standard’, which only requires proper use of HTTP URL and Method.

Cons

No standard and, therefore, hard to manage

The reason that REST is drawing much public attention these days is because non enterprise companies like Google, Yahoo and Amazon are eyeing away from the complexity and difficult standards of web service. As the meanings of data don’t sound like mission critical business requirements, a standard that is easy enough to exchange data transactions would be satisfactory and doesn’t need to be at an enterprise-level. Also there is no company like vendors that wants to take the lead in creating a standard.

There are only standard-looking ones that are used frequently and being created tacitly. (These are called as ‘Defactor standard’.)

As the standards are ambiguous, it becomes a problem in managing them during development. Considering that a clear-cut standard paves the way for a development process or pattern to be created in accordance with several SPECs, a proprietary standard of REST should first be established and used to design a REST-based system. However, in some cases, a misunderstanding on the REST concept can place a REST flag on the wrong architecture. In fact, Flickr.com – a leading runner of WEB 2.0 – once evoked a controversy around REST architecture by putting the name, ‘hybrid REST’ on the API that was designed in a RPC style without internalizing the REST features.

Note. When Flickr’s Hybrid Rest processes a certain operation,

Methods are handed over to query string in the form of http://URL/operation?name=operationname. At a glance, this looks like a RESTful design. But actually the URL for every resource is the same and the operations are simply divided by query string. This goes against the original design principle of REST, which grants a unique URL to every resource.

However, it is worrisome that many local people misunderstand such kind of design as REST and some portals actually offer this kind of services.

As mentioned-above shortly, REST is not a protocol like web service. It is architecture. Because it is a resource-based architecture, system should be designed suitable to the REST concept.

Use of Alternative Key

For example, resource is usually represented by one row from the DB. In the case of DB, primary keys exist in the format of complex keys. (Multiple columns are combined to become one PK, in this case) Although this can be a valid design for the DB, HTTP URL has a hierarchical structure according to / and, therefore, such representation becomes unnatural.

For example, if the PK of DB is defined as “residence registration # of the householder” + “region” + “name,” there is no problem expressing like such in the DB. But this way of definition becomes unnatural (having a strange meaning) when being expressed in REST because it would look like userinfo/{ residence registration # of the householder }/{ region }/{ name}.

In addition, there are many problems in assigning a unique key to a resource and one way to resolve this problem is to use an alternative key (AK). In this case, a unique key with no meaning acts like a key and be used in a field called ‘AK’ within the DB table. Already Google’s REST adopted an architecture using such kind of AK.

However, adding an AK field to the DB means the overall DB design needs to be changed. If this is the case, an architectural approach is required when using REST because the architecture of the overall system must be changed for REST.

Other options to make a RESTful design can include 1) techniques that express the relations between resources through href (link), 2) versioning method, 3) naming rule, 4) cross cutting concern transaction by using ESB, 5) routing, etc. The architecture design method and highly-advanced REST will be covered in the next contribution, titled ‘Highly-Advanced REST Architecture’.

Misunderstanding on REST

REST = HTTP + XML Protocol?

I once proposed to have a discussion on REST at one local community web site on the grounds of designing a highly-advanced REST system for the project. Then, I became to realize that most people simply understood REST as something sending an XML by using HTTP.

Never

REST is an architecture that expresses the resource by best-utilizing the web features. (It is not a protocol) And of course, it must use HTTP. However, XML is not mandatory. It is still ok to use other languages like JSON or YAML. Depending on how well the resource is represented and the web features are utilized determine a correct understanding on the REST architecture concept.

The reason why I am writing this paper is because there is no document that explains the REST concept or principle well enough.

Is REST easier than WebService?

Not exactly. Of course, REST would be much easier than Web Service if being developed from scratch. Because creating a proprietary standard, designing a message with a simple XML, and simply sending that message through HTTP would be required only. However this is looking from a service provider prospective. For those who actually use this service, any XML or JSON data being returned upon request to the HTTP client need to be parsed one by one.

What about web service? Thanks to its clear-cut standard, a web service will be created automatically once the coding takes place based on POJO or JAX-WS. Especially the client stub can be created automatically through WSDL according to the given service contract. For this reason, even though users don’t know the protocol spec at all, web service can be easily utilized as if calling and using a java library.

From my opinion, it looks easier to develop a web service rather than REST. The simplest and the most productive option is a WS-I based web service that is simple enough and well arranged.

Prospect of REST

Not much demand for REST exists in Korea yet. Maybe this is because of users trying to avoid designing highly complicated system or maybe because not much demand has been created for an open-style system.

However already prestigious overseas web sites are offering services under a REST-based architecture. Amazon, one of the representative open API companies is planning to do a REST-based migration on the open APIs previously developed with web service. Although REST is a defector standard, it is known as a difficult standard, which is unavoidable in the web world.

In addition, REST rising from the open side is about to be included in the next JEE6 version as being added as a JAX-RS (JSR311), one of J2EE Specs. (For an open source, REST is included in Apache CXF and a framework called ‘Jersey’ of Sun. Even though REST is translated into a specification, it would be a specification about ‘how’ to implement and still its flexibility will stay unchanged.) A specification called, ‘WADL’ which is similar to ‘WSDL’ of web service has been released as a standard for REST. However, ‘WADL’ only indicates URLs for REST service and yet representing the schema of every message within the actual operations. For this reason, it is right to say that there is no standardized service contract for REST yet, and it is difficult to judge that whether this would serve as an advance or disadvantage in the future.

Conclusion

For its advantage of simplicity and maximum utilization of web features, REST is being spread out surprisingly in the overseas region. As a rare technology developed from the open side, REST has even been adopted as a standard technology (JSR-311).

Still, due to its strong flexibility, REST cannot be controlled or managed easily and, for this reason, hasn’t yet been widely used in the Enterprise System but instead being mostly used for service system. Due to a lack of understanding on the REST concept in Korea as well as inactivated open API, REST is not a popular option yet.

However, it is time for local developers to make preparation for using REST as this concept is becoming main-stream among prestigious international service companies.

In the next contribution, a more sophisticated REST architecture will be covered.

Hello world! July 23, 2009

Posted by Terry.Cho in Uncategorized.
add a comment

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!