The document discusses extending service-oriented architecture (SOA) with REST and Web 2.0 principles. It defines representational state transfer (REST) and describes its characteristics, including being resource-centric, using uniform interfaces, and being stateless. It advocates designing SOAs in a RESTful way by following best practices like using standard HTTP methods and URIs to access resources.
This presentation gives a high level concepts and more of code to take a stab at developing a simple Restful server. I targeted people who would like to build a simple RESTFul server from scratch and experiment.
Representational State Transfer (REST) and HATEOASGuy K. Kloss
Lecture from Auckland University of Technology in the Service-Oriented Architecture for the Master's course in Service-Oriented Computing (semester 2, 2013)
This presentation gives a high level concepts and more of code to take a stab at developing a simple Restful server. I targeted people who would like to build a simple RESTFul server from scratch and experiment.
Representational State Transfer (REST) and HATEOASGuy K. Kloss
Lecture from Auckland University of Technology in the Service-Oriented Architecture for the Master's course in Service-Oriented Computing (semester 2, 2013)
Les Hazlewood, Stormpath co-founder and CTO and the Apache Shiro PMC Chair demonstrates how to design a beautiful REST + JSON API. Includes the principles of RESTful design, how REST differs from XML, tips for increasing adoption of your API, and security concerns.
Presentation video: https://www.youtube.com/watch?v=5WXYw4J4QOU
More info: http://www.stormpath.com/blog/designing-rest-json-apis
Further reading: http://www.stormpath.com/blog
Sign up for Stormpath: https://api.stormpath.com/register
Stormpath is a user management and authentication service for developers. By offloading user management and authentication to Stormpath, developers can bring applications to market faster, reduce development costs, and protect their users. Easy and secure, the flexible cloud service can manage millions of users with a scalable pricing model.
An introduction to REST and RESTful web services.
You can take the course below to learn about REST & RESTful web services.
https://www.udemy.com/building-php-restful-web-services/
What is REST?
What is RESTful Webservices
HTTP-REST Request Basics
HTTP-REST Vocabulary
Authentication (OAuth)
OAuth 2.0 Web Server Flow
REST APIs using Apex REST
Resources
Novelties in Java EE 7: JAX-RS 2.0 + IPT REST HATEOAS Polling Demo @ BGOUG Co...Trayan Iliev
Presentation shows by example (IPT Polling Demo JAXRS20 HATEOAS, https://github.com/iproduct/IPT-Polling-Demo-JAXRS20-HATEOAS/wiki) the novelties in JAX-RS 2.0 and REST HATEOAS:
- Standardized REST Client API;
- Client and server-side asynchronous HTTP request processing;
- Integration of declarative validation using JSR 349: Bean Validation 1.1;
- Improved server-suggested content negotiation;
- Aspect-oriented extensibility of request/response processing using Filters and Interceptors;
- Dynamic extension registration using DynamicFeature interface;
- Hypermedia As The Engine Of Application State (HATEOAS) REST architectural constraint support using state transition links (support for new HTTP Link header as well as JAXB serialization of resource links).
[IPT, http://iproduct.org]
Les Hazlewood, Stormpath co-founder and CTO and the Apache Shiro PMC Chair demonstrates how to design a beautiful REST + JSON API. Includes the principles of RESTful design, how REST differs from XML, tips for increasing adoption of your API, and security concerns.
Presentation video: https://www.youtube.com/watch?v=5WXYw4J4QOU
More info: http://www.stormpath.com/blog/designing-rest-json-apis
Further reading: http://www.stormpath.com/blog
Sign up for Stormpath: https://api.stormpath.com/register
Stormpath is a user management and authentication service for developers. By offloading user management and authentication to Stormpath, developers can bring applications to market faster, reduce development costs, and protect their users. Easy and secure, the flexible cloud service can manage millions of users with a scalable pricing model.
An introduction to REST and RESTful web services.
You can take the course below to learn about REST & RESTful web services.
https://www.udemy.com/building-php-restful-web-services/
What is REST?
What is RESTful Webservices
HTTP-REST Request Basics
HTTP-REST Vocabulary
Authentication (OAuth)
OAuth 2.0 Web Server Flow
REST APIs using Apex REST
Resources
Novelties in Java EE 7: JAX-RS 2.0 + IPT REST HATEOAS Polling Demo @ BGOUG Co...Trayan Iliev
Presentation shows by example (IPT Polling Demo JAXRS20 HATEOAS, https://github.com/iproduct/IPT-Polling-Demo-JAXRS20-HATEOAS/wiki) the novelties in JAX-RS 2.0 and REST HATEOAS:
- Standardized REST Client API;
- Client and server-side asynchronous HTTP request processing;
- Integration of declarative validation using JSR 349: Bean Validation 1.1;
- Improved server-suggested content negotiation;
- Aspect-oriented extensibility of request/response processing using Filters and Interceptors;
- Dynamic extension registration using DynamicFeature interface;
- Hypermedia As The Engine Of Application State (HATEOAS) REST architectural constraint support using state transition links (support for new HTTP Link header as well as JAXB serialization of resource links).
[IPT, http://iproduct.org]
DockerCon US 2016 - Docker Practice in Alibaba CloudLi Yi
China is the biggest emerging market for Cloud computing, with strong momentum in both business and technology. As the leading cloud provider in China, Alibaba Cloud commits to open container technologies.
In this session, we will share use cases from Docker practices in Alibaba Cloud. It will cover topics including: deploying cloud native applications combined with Container and Cloud Service with one-click through Container Service; delivering and maintain dedicated cloud efficiently with Docker; a scalable, distributed architecture for global distribution of Docker image. Join us to hear how to align customer's business needs with cutting edge container technologies.
Basics of API Design and development. After the presentation, we developed a python flask-based app that you use to remind yourself anything via an api https://github.com/oquidave/reminderme
Best Practices for Architecting a Pragmatic Web API.Mario Cardinal
This presentation teach how to design a real-world and pragmatic web API. It draws from the experience Mario Cardinal have gained over the years being involved architecting many Web API. This presentation begins by differencing between a Web and a REST API, and then continue with the design process. We conclude with the core learnings of the session which is a review of the best practices when designing a web API. Armed with skills acquired, you can expect to see significant improvements in your ability to design a pragmatic web API.
This is the presentation from Null/OWASP/g4h December Bangalore MeetUp by Akash Mahajan.
technology.inmobi.com/events/null-owasp-g4h-december-meetup
Abstract:
This will cover the basics of Hyper Text Transfer Protocol. You will learn how to send HTTP requests like GET, POST by crafting them manually and using a command line tool like CURL. You will also see how session management using cookies happens using the same tools.
To practice along please install curl (http://curl.haxx.se/download.html).
Web Component Development Using Servlet & JSP Technologies (EE6) - Chapter 4...WebStackAcademy
Setting up a servlet environment
Servlets are Java programs that run on a Web server and build Web pages. Here are a few definitions:
Servlet Development Kits
Java Servlet Development Kit (JSDK) provides Servlet API classes (servlet.jar). Place servlet.jar into CLASSPATH, so that java classes can access it.
Servlet Engines
A servlet is a Java class that needs to be executed in a Java VM by servlet engine. The servlet engine loads the servlet class the first time the servlet is requested. The servlet then stays loaded to handle multiple requests until it is explicitly unloaded or the servlet engine is shut down.
Following are few WebServers that supports servlets:
Apache Tomcat
BEA WebLogic
IBM Websphere
Sun's Java Web Server (JWS)
Apache Tomcat.
Java Servlet Development Kit (JSDK)
KaTe RESTful adapter for SAP Process Integration: IntroductionKate_RESTful
Introduction and sample walktrough of the KaTe RESTful adapter for SAP Process Integration
http://kate-group.de/sap-beratung-services-projektmanagment/sap-rest-adapter/
This presentation will discuss how the Representational State Transfer (REST) architectural style can be applied to the design of your web services.
You will learn how to use HTTP methods and status codes properly and we will discuss how to use Hypermedia As The Engine Of Application State (HATEOAS). The principles of REST and HATEOAS will be demonstrated through the Atom Publishing Protocol (AtomPub) using the Google Data APIs and other AtomPub implementations as examples.
REST & RESTful Web Service
REST stands for Representational State Transfer
REST web services communicate over the HTTP specification, using HTTP vocabulary
If a service does not include all constraints it is not a RESTful web service.
24. Caching in The Web User Agent Origin Server Proxies Gateways C C C C
25. Caching in The Web User Agent Origin Server Proxies Gateways C C C C ... Server: Apache ETag: "85a1b765e8c01dbf872651d7a5" Content-Type: text/html Cache-Control: max-age=3600 ...
26. Real World of the Web Client Cache Router Firewall ISP Proxy Server Firewall Web Server Resources Firewall Web Server Reverse Proxy Resources
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44. Cache Example 1 http://tomayko.com/writings/things-caches-do
58. From Open API to Next Generation Open Business Model
59.
60.
Editor's Notes
Any simple sample:
REST is not a standard You will not see the W3C putting out a REST specification. You will not see IBM or Microsoft or Sun selling a REST developer's toolkit. REST is just a design pattern You can't bottle up a pattern. You can only understand it and design your Web services to it. REST does prescribe the use of standards: HTTP URL XML/HTML/GIF/JPEG/ etc. (Resource Representations) text/xml, text/html, image/gif, image/jpeg, etc. (Resource Types, MIME Types)
Principles of REST Resource centric approach All relevant resources are addressable via URIs Uniform access via HTTP – GET, POST, PUT, DELETE Content type negotiation allows retrieving alternative representations from same URI REST style services are easy to access from code running in web browsers, any other client or servers can serve multiple representations of the same resource
03/04/09 Get to know your HTTP statuses. Do not add semantics that they were not intended for.
If you follow these semantics through, algorithmic resources are those that at first seems like you have to introduce a new verb, or dump REST. But in actuality, using REST for a Façade makes you think of Audting straight from the beginning. Consider a Transfer. If you make the Transfer process a resource, then you have to follow the HTTP Semantics. POST executes the Transfer, GET gives records of transfer. Delete and PUT can have affects for transfers that are in progress.
03/04/09 A Resource can be anything from a piece of data in a database, to an algorithm. You need to determine the type of resource you have in your design. This will help you formulate the correct URI patterns.
Simple resources are easy. You can have a resource like instructions. You can further filter the instructions down, into chapters. This provides a more complex type with specialized views.
03/04/09 A Collection is made up of one or more members. An example of a container is a BookShelf. A BookShelf has Books as a member. You may choose to have an HTTP GET to URI of /bookshelf serve up a list of books. In most cases though, a container type is named after the members, so that /book or /books could also be valid URI’s for collections of books. Ordered collections are ordered by index. When you access the collection without any modifiers they will be ordered by the id. Ordered collections can be sparse in that there is no guarantee that a particular index entry is present, only that they would be ordered. When a collection is not sparse, you are guaranteed to have all the indexes (eg., 1,2,3,4,5,etc). A sparse collection will allow (1,2,5,7,8). Collections can be unordered. In this case, when you access the container, there is no guarantee of order. For example, my bookshelf at home has my books in no particular order. There is no guarantee that the books are ordered when accessing the collection without any modifiers.
03/04/09 Several Development groups had a notion on Filter.. .others didn’t have anything (but passed them as query params). If you are going to do this in your organization, you should standardize on a common approach… . Here’s one example of a commons approach. Sometimes your implementation platform will make the decision for you. For example, JPA Based back end may allow you to pass JPA Expression, ADO for .NET provides REST layer for their back end.
03/04/09 Ordered Collection paging on members works well if the keys are integers that are not sparse. However, most of the time the collection will not be able to specify specific ranges. Start and count (or end) works well on any type collection. For ordered collections, the start query parameter must correspond to the id. For unordered collections, it can be mapped to any field, or any algorithm you specify. For example, you may use it to set the cursor position in an arbitrary result set in a query. Some HTTP Range headers may be tempting, but these actually wrok on bytes, and used by network layers to do optimal chuncking of data.
03/04/09 You can pass a comma separated list of columns to do sorting on more than one field. This can be used by ordered and unordered collection. In this slide we see the use of a sort and sortBy parameter.
03/04/09 In content negotiation, the resource representation returned is selected by the client through the use of several &quot;Accept&quot; headers, as defined in the HTTP specification. The <dot notation> works well for static resources. For example, if you have a document.html and document.pdf stored in your Web server, these are two different resources. However, using the <dot notation> as a means for asking for a different format of the same resource can cause confusion if the resource is dynamic. This is because, in the static case, the <dot notation> means two different resources, while in the dynamic case, it is the same resource. In addition, media type is just one content negotiation type. If you combine that with the others discussed earlier, then you could end up with funny looking URLs. For example, if you wanted an isso-8859 JSON version of a resource in English, then you would end up looking for a URI like this: /document.json.en.iso-8859-5. Query parameters are often used for content negotiations. The reason this happens is because developers often use the browser to quickly test and see results. Adding query parameters often provide a quick way to do this. Query parameters do not give the illusion that you are dealing with a different resource. However, dynamic RESTFul services are usually built to be used by client applications, either from a browser using Ajax or from another server application. Altering the URI in order to accomplish content negotiation is convenient for sharing a link to a specific resource representation or testing in a browser. However, applications should rely on standard HTTP headers first and selected URI conventions second. Query parameters are usually meant to provide input to a service, such as filtering criteria, sorting, and other business level details. Using headers for content negotiation separates IT concerns from business ones. In addition, requests usually pass through firewalls, proxies, and other servers. These HTTP proxies often understand the standard HTTP header and might provide caching and other nonfunctional requirements. As a compromise, you can provide a query parameter for development time and then disable it when deploying the application. In general, application clients should use the simplest technique. Many of the HTTP headers were designed with networking in mind, and helping browsers and intermediate proxies to automate exchange of information. Business applications often do not need this level of sophistication. he HTTP specification defines several techniques for content negotiation. This presentation addresses what is referred to as server-driven content negotiation. There are other types meant more for network proxies.
03/04/09 The Accept request-header field can be used to specify certain media types responses that are acceptable to the client. Accept headers can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request for an in-line image. Examples include: application/json, application/atom+xml, and text/html. The Accept-Charset request-header field can be used to indicate in which character sets the response should be represented that are acceptable to the client. This field enables clients capable of understanding more comprehensive or special-purpose character sets to signal that capability to a server that is capable of representing documents in those character sets. The Accept-Encoding request-header field is similar to Accept, but restricts the content-codings. For example, you can use this field to indicate compression. Example values: compress;q=0.5, gzip;q=1.0. The Accept-Language request-header field is similar to Accept, but restricts the set of natural languages that are preferred as a response to the request. Examples include: en for English, es for Spanish.
03/04/09 This is a simple example of an HTTP request without caching. Here requests and responses just get forwarded.
03/04/09 Here we have a simple example using the Cache-Control HTTP Header. The service provider response with a response header and send it back to the client.
03/04/09 Since cache is fresh – and hasn’t expired – data is returned (and not hit on server). Here we are relying on the age of the resource.
03/04/09 The Last-Modified and E-Tag headers are a more robust solution. Here we get back an E-Tag and last modified header in the response for an initial GET.
03/04/09 Caching (where a response isn’t having to be sent) – since the requesting client (i.e. the cache) already has information that is still relevant. Cache checks with provider, provider returns simple HTTP code instead of data. We will see examples later where these same headers are used for Optimistic concurrency control.
03/04/09 Caching should only be used on GET. POST/PUT/DELETE would invalidate cache and start the process again. Calculating etags may not be easy, but mapping it to something like a JPA version number may be ideal.
03/04/09 Because Resources are communicated over HTTP, in a stateless fashion, optimistic concurrency patterns should be employed for resources that you plan to update or where having the latest copy is essential. Optimistic concurrency at the REST level does not live alone. Because you have physical underlying artifacts that you might be RESTifying, you have to work with underlying mechanisms. For example. If you are using database or JPA objects in your application and you are releasing this data via REST, then you have to work with the optimistic concurrency of that layer, such as a version column or JPA @Version annotation, and with the REST layer. You can pass this information as part of the payload, but, the downside is that only consumers and producers know about them. As we learned in the caching section, http headers are used to allow caching patterns. If consumers use these same headers, then they can employ optimistic concurrency and be in sync with caches inbetween.
03/04/09 This slide shows an interaction between a consumer and provider. When working with shared resources that need updating, a consumer should issue a GET. A Provider should populate the Etag header with a version number or timestamp. When the consumer updates the resource, it should populate the If-Match header with the value it received from the Etag. The provider should check the version number against that of the physical data (column, JPA version) and if they match, perform the update, if not, return 412 HTTP Response code, which means that the condition failed. Addtiional headers such as If-Modified-Since can be used for conditional GET on resource you have had for a while. If-None-Match can be used for conditional updates, though not typical of a consumer.
03/04/09 The beauty of REST is that it sits on top of the existing HTTP infrastructure. So follow all the same HTTP Security rules, lock down all URLS, URLS map one to one with services, allows for better ACL to finer grained things. Make sure you go to Keys Security Lecture.
03/04/09 REST Services themselves may not be the only thing, but the consumers and the behavior the REST can lead to. REST is often used to Mashup data. Mashups acces many REST resources and combine them on the glass. This can lead to cross site scripting and malicious content from third parties. Make sure you use server proxies to tunnel all ajax behavior through. Something like DataPower or the Ajax Proxy in WAS can provide a White List and Black list of third parties. It can also do things like inspect content. Browser applications should not do eval from third party JSON, but parse it.
Essentially Web 2.0 = new ways of using the web. New, easy to use technologies enabling more people to participate. Enterprises are starting to undergo the same shift and we can accelerate that by embracing these new technologies. This flexibility helps our clients adopt new business models. There are challenges, but IBM is in a unique position to
Ecommerce as the sample
03/04/09 Resources which explain how web caching works (I’ve added links to) – apart from the RFC 2616 (i.e. the HTTP 1.1 specification which I posted earlier). Responses to GET requests are usually the only requests where caching can occur (as the others are not idempotent) HTTP headers can contain caching directives to inform the caches how to interpret data in a request/response. Interesting headers to note are: Expires: The expires header is a basic means for controlling caches and tells how long the resource representation in the response returned is good for. After that time, a cache will request an update from the target resource. If you are going to design resources (and their data content is somewhat stagnant) – consider using Expires: as an HTTP header to reduce load on resources. The issues with Expires are that clocks are not synchronized, and that users may forget to update the time/date of the expiration. Cache-Control: .Cache-control attempts to give more control over Expires. It can include time that the representation is considered fresh (which is a relative time). It’s a relative time over when the request was issued. If neither header was set – no validation will occur and caches will not store any representation at all. If a cache stores information, and it includes a Last-Modified : tag, the cache can ask a server whether or not a resource has been modified (with an If-Modified-Since) tag. However – I’ll defer some of that discussion for a second. Lastly – HTTP 1.1 introduced a notion of Entity Tags (or Etag). An Etag is a unique identifier that is generated by the server and changed every time the representation changes. Because the server controls how Etags are generated, caches can be sureer if the Etag matches when they make a If-None-Match request , the representation is realy the same. Almost all caches use Last-Modified times in determining whether a representation is fresh. Again – let’s hold off for a couple of slides on the remaining items when I talk about concurrency control.