RESTful Web Services

Urls
- Short, Meaningful, Predictable, Readable urls
- Nouns, not verbs
- Lower case
- Use hypens rather than spaces or underlines
- Use a plural path for collections
- Put individual resources under the plural collection path.
- Favor hackable urls over direct urls.

Idempotent
stateless
versioned
PATCH - to update parts of a resource, update one or more fields as opposed to all fields.
Define SLA

actions
POST /transactions
from=1&to=2&amount=500.00

REST is a term coined by Roy Fielding in his Ph.D. dissertation to describe an architecture style of networked systems.
REST is an acronym standing for Representational State Transfer, REST defines a set of architectural principles by which you can design Web services that focus on a system's resources, including how resource states are addressed and transferred over HTTP by a wide range of clients written in different languages.
REST is a key design idiom that embraces a stateless client-server architecture in which the web services are viewed as resources and can be identified by their URLs.
Web service clients use a small globally defined set of remote methods, such as GET, Put, POST, and DELETE to access and manipulate the resource. REST is an analytical description of the existing web architecture, and thus the interplay with HTTP protocol appears seamlessly.
REST isn’t protocol-specific, but they usually mean REST over HTTP.
The HTTP methods such as GET, PUT, POST, DELETE are the verbs that the developer can use to describe the necessary create, read, update, and delete (CRUD) actions to be performed.
REST has had such a large impact on the Web that it has mostly displaced SOAP- and WSDL-based interface design because it's a considerably simpler style to use.
Motivation for REST
The motivation for REST was to capture the characteristics of the Web which has made the Web successful. 
REST is an Architectural Style, not a standard.
REST Web Services Characteristics
Here are the characteristics of REST:
  • REST is a pull-based interaction style client-server model.
  • Named and addressable resources
         The key abstraction of information and data in REST is a resource, and the system is comprised of resources which are named using a URI. (Uniform Resource Identifier)
  • A uniform, constrained interface
         All resources are manipulated with a generic interface (e.g., HTTP GET, POST, PUT, DELETE).
         Advantages:

    1. Familiarity
    2. Interoperability
    HTTP is a very ubiquitous protocol. Most programming languages have an HTTP
    1. client library available to them.
  • Communicate stateless
        Stateless applications are easier to scale to meet increasingly high performance demands; each request from client to server must contain  all the information necessary to understand the request.
        Stateless services are less complicated to design, write, and distribute across load-balanced servers. A stateless service performs better and shifts most of the responsibility of maintaining state to the client application. 
        Advantages:
    1. Scalability
                  We can reuse the rich and configurable caching semantics defined in HTTP, such as client browser cache, procy etc.
  • Hypermedia As The Engine Of Application State (HATEOAS)
    Let your data formats drive state transitions in your applications.
One of the uses of hypermedia and hyperlinks is composing complex sets of information from disparate sources. Hyperlinks allow us to reference and aggregate additional data without bloating our responses.
with each request returned from a server it tells you what new interactions you can do next, as well as where to go to transition the state of your applications.
     Miscs 
  • Cache: A caching infrastructure can be leveraged for performance; GET method can normally be cacheable.
  • Use HTTP methods explicitly, RESTful Web service uses Put, GET, POST, and DELETE to create, retrieve, change and delete a resource.
  • Expose directory structure-like URIs, REST Web services normally use directory structure-like URIs,
http://www.myservice.org/discussion/topics/{topic}
http://www.myservice.org/discussion/{year}/{day}/{month}/{topic}
This kind of URI is straightforward, predictable, and easily understood.
    * Interconnected resource representations - the representations of the resources are interconnected using URLs, thereby enabling a client to progress from one state to another. We can put hyperlinks within resource representations to enable clients to drill down for more information, and/or to obtain related information
    * Layered components - intermediaries, such as proxy servers, cache servers, gateways, etc, can be inserted between clients and resources to support performance, security, etc.
Principles of REST Web Service Design
1. The key to creating Web Services in a REST network (i.e., the Web) is to identify all of the conceptual entities that you wish to expose as services.
2. Create a URL to each resource. The resources should be nouns, not verbs.
3. Categorize your resources according to whether clients can just receive a representation of the resource, or whether clients can modify (add to) the resource. For the former, make those resources accessible using an HTTP GET. For the later, make those resources accessible using HTTP POST, PUT, and/or DELETE.
4. All resources accessible via HTTP GET should be side-effect free. That is, the resource should just return a representation of the resource. Invoking the resource should not result in modifying the resource.
5. No representation should be an island, put hyperlinks within resource representations to enable clients to drill down for more information, and/or to obtain related information.
6. Design to reveal data gradually. Don't reveal everything in a single response document. Provide hyperlinks to obtain more details.
7. Specify the format of response data using a schema. For those services that require a POST or PUT to it, also provide a schema to specify the format of the response.
8. Describe how your services are to be invoked using either a WADL document, or simply an HTML document.
RESTful Support in JAX-WS
The Java API for XML Web Services (JAX-WS) provides full support for building and deploying RESTful web services, The API was developed through JSR 224, JSR-311.


Resources:
RESTful Java with Jax-RS (Animal Guide)
RESTful Web services: The basics
RESTful Web Services
Representational State Transfer (REST) - Roy Fielding
Post a Comment

Labels

Java (159) Lucene-Solr (110) Interview (61) All (58) J2SE (53) Algorithm (45) Soft Skills (36) Eclipse (34) Code Example (31) Linux (24) JavaScript (23) Spring (22) Windows (22) Web Development (20) Nutch2 (18) Tools (18) Bugs (17) Debug (16) Defects (14) Text Mining (14) J2EE (13) Network (13) Troubleshooting (12) PowerShell (11) Chrome (9) Design (9) How to (9) Learning code (9) Performance (9) UIMA (9) html (9) Http Client (8) Maven (8) Problem Solving (8) Security (8) bat (8) blogger (8) Big Data (7) Continuous Integration (7) Google (7) Guava (7) JSON (7) ANT (6) Coding Skills (6) Database (6) Scala (6) Shell (6) css (6) Algorithm Series (5) Cache (5) Dynamic Languages (5) IDE (5) Lesson Learned (5) Programmer Skills (5) Tips (5) adsense (5) xml (5) AIX (4) Code Quality (4) GAE (4) Git (4) Good Programming Practices (4) Jackson (4) Memory Usage (4) Miscs (4) OpenNLP (4) Project Managment (4) Spark (4) System Design (4) Testing (4) ads (4) regular-expression (4) Android (3) Apache Spark (3) Become a Better You (3) Concurrency (3) Eclipse RCP (3) English (3) Happy Hacking (3) IBM (3) J2SE Knowledge Series (3) JAX-RS (3) Jetty (3) Restful Web Service (3) Script (3) regex (3) seo (3) .Net (2) Android Studio (2) Apache (2) Apache Procrun (2) Architecture (2) Batch (2) Bit Operation (2) Build (2) Building Scalable Web Sites (2) C# (2) C/C++ (2) CSV (2) Career (2) Cassandra (2) Distributed (2) Fiddler (2) Firefox (2) Google Drive (2) Gson (2) How to Interview (2) Html Parser (2) Http (2) Image Tools (2) JQuery (2) Jersey (2) LDAP (2) Life (2) Logging (2) Python (2) Software Issues (2) Storage (2) Text Search (2) xml parser (2) AOP (1) Application Design (1) AspectJ (1) Chrome DevTools (1) Cloud (1) Codility (1) Data Mining (1) Data Structure (1) ExceptionUtils (1) Exif (1) Feature Request (1) FindBugs (1) Greasemonkey (1) HTML5 (1) Httpd (1) I18N (1) IBM Java Thread Dump Analyzer (1) JDK Source Code (1) JDK8 (1) JMX (1) Lazy Developer (1) Mac (1) Machine Learning (1) Mobile (1) My Plan for 2010 (1) Netbeans (1) Notes (1) Operating System (1) Perl (1) Problems (1) Product Architecture (1) Programming Life (1) Quality (1) Redhat (1) Redis (1) Review (1) RxJava (1) Solutions logs (1) Team Management (1) Thread Dump Analyzer (1) Visualization (1) boilerpipe (1) htm (1) ongoing (1) procrun (1) rss (1)

Popular Posts