REST-based Web Services (I) - UNSW Sites
REST-based Web Services (I) Helen Paik School of Computer Science and Engineering University of New South Wales Resources: RESTful Web Services by L. Richardson and S. Ruby, O’Reilly (http://oreilly.com/catalog/9780596529260) ICSOC 2008 Summer School session on REST-based Services – article: How to get a cup of coffee by Jim Webber w) Building Web Services the REST Way, By Roger L. Costello – http://www.xfront.com/REST-Web-Services.html Acknowledgement: The slides are adapted from ‘RESTful Web Services’ chapters 4, some of the slides are from the previous sessions prepared by Dr. Adnene Guabtni and Dr. Sherif Sakr. Week 6 H. Paik (CSE, UNSW) REST Week 6 1 / 54
What is REST and Why REST REST is an architectural style guide of building networked systems. It is popularised as a guide to build modern distributed applications on the Web Drivers of REST interoperability between heterogeneous systems (i.e., integrating applications that are built using different languages and run on different platforms) . Think News sites rise of different client devices . not just phones. Think iCar, iWatch scailability . a (potentially) large number of clients this kind of broad integration is only possible if the way the involved services (providers/consumers) interact with each other is based on a set of simple, consistent and reliable principles REST itself is not an official standard specification or even a recommendation. It is just a “design guideline” for building a system (or a service in our context) on the Web H. Paik (CSE, UNSW) REST Week 6 2 / 54
REST philosophy: Resource-Oriented Architecture Main objective of REST is to expose resources on a networked system (the Web) What is a Resource? A resource is anything that is important enough to be referenced as a ‘thing’ in itself. If you want to create a hypertext link to it, make or refute assertions about it, retrieve or cache a representation of it, include all or part of it by reference into another representation, annotate it, or perform other operations on it, then you should make it a resource. 1 Usually, a resource is something that can be stored on a computer and represented as a stream of bits: a document, a payment, or the result of running an algorithm, a photo, a resume, an employee, a blog posting . 1 The text is from the O’Reilly book RESTful Web Services H. Paik (CSE, UNSW) REST Week 6 3 / 54
REST philosophy In REST, everything starts and ends with resources. What is a Resource? A resource is a thing that: is unique (i.e., can be identified uniquely) has at least one representation, has one or more attributes beyond ID has a potential schema, or definition can provide context is reachable within the addressable universe H. Paik (CSE, UNSW) REST Week 6 4 / 54
Resource Representation(s) H. Paik (CSE, UNSW) REST Week 6 5 / 54
But before we move on . Let us clear up a few things about URI, URL and URN A uniform resource identifier (URI) is a string of characters used to identify a name or a resource in a network (typically World Wide Web) Why do we need it? . URI: URI schemes specify an exact syntax (i.e., what it looks like) and associated protocols (i.e., how it is used) for each URI . URI schemes ? (http://en.wikipedia.org/wiki/URI scheme) URI examples (with different schemes): instruct/editors/editors.pdf URN:ISBN:952-10-0093-7 http://www.cse.unsw.edu.au H. Paik (CSE, UNSW) REST Week 6 6 / 54
But before we move on . URL is a URI. in addition to being a resource identifier, it specifies the means for finding it (i.e., locating/obtaining it over the network) common URI schemes for URL http:, ftp:, mailto:, file: should give you ’Not Found’ error (i.e., unable to locate) URN is a URI. it uses a URI scheme called URN to name resources (similar to naming a person) examples (global URN schemes): urn:isbn:0451450523 (The Last Unicorn (1968 book), book number) urn:isan:0000-0000-9E59-0000-O-0000-0000-2 (Spider-Man (2002 film), audiovisual number) urn:ietf:rfc:2648 (IETF’s RFC 2648) should not give you ’Not Found’ error - it is not a locator H. Paik (CSE, UNSW) REST Week 6 7 / 54
Resource ID, Representations and Descriptions Let’s say a company exposes the following URLs as pointers to their employees: http://www.example.com/people/alice (the homepage of Alice) http://www.example.com/people/bob (the homepage of Bob) Strictly speaking, in the above URLs, we are mixing up the identity of a resource and descriptions/representations of it . This may not be desirable, if we want to manage (and build services on) resources that are not Web pages . such as people, products, places, ideas/concepts, etc. Using http://www.example.com/people/alice as both the ID, as well as a Web document does not quite work . e.g., How do we answer a question: How old is http://www.example.com/people/alice ? How to represent that Bob may not like the look of the homepage, but fancy the person Alice. H. Paik (CSE, UNSW) REST Week 6 8 / 54
Resource ID, Representations and Descriptions So two URIs are needed, one for Alice, one for the homepage. Or maybe more than two if Alice should have multiple representations: e.g., a HTML document, a photo of her, a PDF document. Using URIs, it is possible to identify both a thing (which may exist outside of the Web) and a Web document describing the thing. Possible solutions: http://www.example.com/about#alice http://www.example.com/id/alice (Identifier for Alice, the person) (Identifier for Alice, the person) - redirected to http://www.example.com/people/alice - redirected to http://www.example.com/data/alice (Alice’s homepage) (XML document with description of Alice) H. Paik (CSE, UNSW) REST Week 6 9 / 54
Origins of REST REST is an acronym standing for Representational State Transfer. First introduced by Roy T. Fielding in his PhD dissertation ”Architectural Styles and the Design of Network-based Software Architectures” http://www.ics.uci.edu/ fielding/pubs/dissertation/top.htm be-hypertextdriven He proposed REST as a design guide for a modern Web software system by applying ‘a set of architectural style constraints’ to the elements within the Web architecture REST is client-server where a representation of the resource is exposed to the client application. always assumes a disconnected system - interface/contract H. Paik (CSE, UNSW) REST Week 6 10 / 54
REST principles (I): Resource Identification Resources are identified by a URI (Uniform Resource Identifier) gz A resource has to have at least one URI Most known URI type are URL and URN URN (Uniform Resource Name) urn:isbn:0-486-27557-4 (a specific edition of Shakespeare’s play Romeo and Juliet) URL (Uniform Resource Locator) file:///home/tommy/plays/RomeoAndJuliet.pdf Every URI designate exactly one resource cf. what about: .gz http://www.example.com/software/releases/latest H. Paik (CSE, UNSW) REST Week 6 11 / 54
REST principles (II): Addressability An application is ’addressable’ if it exposes its data set as resources (i.e., usually an infinite number of URIs) Filesystem on your computer is addressable system The cells in a spreadsheet are addressable (cell referencing) Google is addressable: a resource ’http://www.google.com.au/search?q unsw’ you can bookmark, use it as link in a program, you can email, etc. REST advocates addressability as a main feature of its principles This seems natural, the way the Web should work, but many applications don’t work this way all the time H. Paik (CSE, UNSW) REST Week 6 12 / 54
REST principles (III): Statelessness Stateless means every HTTP request happens in a complete isolation. When client makes an HTTP request, it includes necessary information for the server to fulfil the request H. Paik (CSE, UNSW) REST Week 6 13 / 54
REST principles: Statelessness There are many Web sites that expects you to make requests in a certain order: A, B, then C. – There are sections in the system where you can only reach via building up certain ‘interaction state’ on the server . H. Paik (CSE, UNSW) REST Week 6 14 / 54
REST principles: Statelessness Stateless is good !! - scalable, easy to cache, addressable URI can be bookmarked (e.g., 10th page of search results) HTTP is by nature stateless We do something to break it the most common way to break it is ’HTTP sessions’ the first time a user visits your site, he gets a unique string that identifies his session with the site http://www.example.com/forum?PHPSESSIONID 27314962133 the string is a key into a data structure on the server and the data structure that contains the state all interactions assume the key to be available to manipulate the data on the server H. Paik (CSE, UNSW) REST Week 6 15 / 54
REST principles: Statelessness What counts as ‘state’ exactly? application state vs. resource state Think a Flickr.com-like web site . you will add photos, rename photos, share them with friends, etc. – what would ‘being stateless’ mean here? Two kinds of states photos are resources client applications access those resources per their application logic resource state live on the server (i.e., photos are stored on the server) individual client application states (i.e., photos John clicked on) should be kept off the server consider the application state as data that could vary by client, and per request. e.g., Google’s resources – indexed web pages. Client application state – your query and your current page (different for every client because each client takes a different ’path’ to their current state) H. Paik (CSE, UNSW) REST Week 6 16 / 54
REST principles: Statelessness Statelessness in REST applies to the client application state REST principle says: URI should contain the necessary state to handle the request within the request itself, whether as part of the URI, query-string parameters, body, or headers. The URI uniquely identifies the resource and the body contains the state (or state change) of that resource. i.e., every REST request should be totally self-descriptive a RESTful service requires that the application state to stay on the client side server does not keep the application state on behalf of a client client transmit the state to the server for every request that needs it Resource state is the same for every client and its state is managed on the server. H. Paik (CSE, UNSW) REST Week 6 17 / 54
REST principles: Statelessness e.g., being client-aware (i.e., stateful): Say every client has to send an API key to a server to access an operation so that the server can restricts you to a certain number of requests a day . the number of requests made is client state (different for every client) but the server will not trust the client to self-report the its state honestly . so the ’count’ for individual client will be stored on the server - i.e., creating a server-side client state Consequences: scalability is not as good . if the service is distributed across multiple machines, every machine in a cluster needs to know client A is on request number X and so on. or load balancer needs to make sure that every client A request goes to the same machine Roy Fielding says: Like most architectural choices, the stateless constraint reflects a design trade-off. H. Paik (CSE, UNSW) REST Week 6 18 / 54
REST principles (IV): Resource Representations A resource needs a representation for it to be sent to the client a representation of a resource - some data about the ’current state’ of a resource (i.e., a list of open bugs) a list of open bugs – in XML, a web page, comma-separate-values, printer-friendly-format, etc. when a representation of a resource may also contain metadata about the resource (e.g., books: book itself metadata such as cover-image, reviews, stock-level, etc.) Representation can flow the other way too: a client send a new or updated ’representation’ of a resource and the server creates/updates the resource. H. Paik (CSE, UNSW) REST Week 6 19 / 54
REST principles: Resource Representations Deciding between multiple representations Option 1. Have a distinct URI for each representation of a resource: http://www.example.com/release/104.en (English) http://www.example.com/release/104.es (Spanish) http://www.example.com/release/104.fr (French) This also meets the addressability and statelessness principles in that the server knows all info necessary for the server to fulfil the request H. Paik (CSE, UNSW) REST Week 6 20 / 54
REST principles: Resource Representations Deciding between multiple representations Option 2. Use HTTP HEAD (metadata) for content negotiation: expose, e.g., http://www.example.com/release/104 client HTTP request contains Accept-Language Other types of request metadata can be set to indicate all kinds of client preferences, e.g., file format, payment information, authentication credentials, IP address of the client, caching directives, and so on. Option 1 or 2 are both acceptable REST-based solution . but addressable URI option is preferred. e.g., Say you want to use a HTML page translation service which accepts URI . which representation offer will give you the most flexibility? H. Paik (CSE, UNSW) REST Week 6 21 / 54
REST principles (V): Links and Connectedness In REST, resource representations are hypermedia: resource (data itself) links to other resources e.g., Google Search representation: H. Paik (CSE, UNSW) REST Week 6 22 / 54
REST principles: Links and Connectedness R. Fielding talks about: “Hypermedia as the engine of application state” The current state of an HTTP ‘session’ is not stored on the server as a resource state, but tracked by the client as an application state, and created by the path the client takes through the Web. The server guides the client’s path by serving hypermedia: links and forms inside resource representations. The server sends the client guidelines about which states are near and current one. H. Paik (CSE, UNSW) REST Week 6 23 / 54
REST principles: Links and Connectedness Connectedness in REST All three services expose the same functionality, but their usability increases towards the right Service A is a typical RPC-style, exposing everything through a single URI. Neither addressable, nor connected Service B is addressable but not connected; there are no indication of the relationships between resources. A hybrid style . Service C is addressable and well-connected; resources are lined to each other in ways that make sense. A fully RESTful service H. Paik (CSE, UNSW) REST Week 6 24 / 54
REST principles (VI): Uniform Interface REST Uniform Interface Principle has 4 HTTP main operations on resources Discuss input/output of the following. PUT: Create a new resource (new URI) or update a resource (existing URI) GET: Retrieve a representation of a resource. POST*: Modify the state of a resource. POST is a read-write operation and may change the state of the resource and provoke side effects on the server. Web browsers warn you when refreshing a page generated with POST. DELETE: Clear a resource, after the URI is no longer valid HEAD and OPTIONS Similar to the CRUD (Create, Read, Update, Delete) databases operations *POST: a debate about its exact best-practice usage . H. Paik (CSE, UNSW) REST Week 6 25 / 54
REST principles: Uniform Interface H. Paik (CSE, UNSW) REST Week 6 26 / 54
REST principles: Uniform Interface REST Uniform Interface, if properly followed, gives you two properties: being Safe Read-only operations . The operations on a resource do not change any server state. The client can call the operations 10 times, it has no effect on the server state. (like multiplying a number by 1, e.g., 4x1, 4x1x1, 4x1x1x1, .) being Idempotent Operations that have the same “effect” whether you apply it once or more than once. An effect here may well be a change of server state. An operation on a resource is idempotent if making one request is the same as making a series of identical requests. (like multiplying a number by 0, e.g., 4x0, 4x0x0, 4x0x0x0, .) H. Paik (CSE, UNSW) REST Week 6 27 / 54
REST principles: Uniform Interface Safety and Idempotence GET: safe HEAD and OPTION: safe PUT: - idempotent If you create a resource with PUT, and then resend the PUT request, the resource is still there and it has the same properties you gave it when you created it. If you update a resource with PUT, you can resend the PUT request and the resource state won’t change again DELETE: - idempotent If you delete a resource with DELETE, it’s gone. You send DELETE again, it is still gone ! H. Paik (CSE, UNSW) REST Week 6 28 / 54
REST principles: Uniform Interface Why Safety and Idempotence matter The two properties let a client make reliable HTTP requests over an unreliable network. Your GET request gets no response? make another one. It’s safe. Your PUT request gets no response, make another one. Even if your earlier one got through, your second PUT will have no side-effect. There are many applications that misuse the HTTP uniform interface. e.g., GET https://api.del.icio.us/posts/delete GET www.example.com/registration?new true&name aaa&ph 123 Many expose unsafe operations as GET and there are many use of POST operation which is neither safe nor idempotent. Repeating them has consequences . H. Paik (CSE, UNSW) REST Week 6 29 / 54
REST principles: Uniform Interface Why Uniform Interface matters Uniformity The point about REST Uniform Interface is in the ’uniformity’: that every service use HTTP’s interface the same way. It means, for example, GET does mean ’read-only’ across the Web no matter which resource you are using it on. It means, we do not use methods in place of GET like doSearch or getPage or nextNumber. But, it is not just using GET in your service, it is about using it the way it was meant to be used. H. Paik (CSE, UNSW) REST Week 6 30 / 54
Brief Recap of REST principles Resources: Resource: Any *thing* (noun) that is worthy of being given a unique ID and be accessible via client. The ID is given in form of (.) The state of a resource is managed by (.) Resources must have (.) to be ’transmitted’ to client Give an example of a resource and its representations ? H. Paik (CSE, UNSW) REST Week 6 31 / 54
Brief Recap of REST principles Uniform Interface: Uniform ‘verbs’ that go with the resources (noun) Given a resource (coffee order): a representation in XML order xmlns "urn:starbucks" drink latte /drink /order What does the following operations mean (and what do they return)? POST /starbucks/orders GET /starbucks/orders/order?id 1234 PUT /starbucks/orders/order?id 1234 DELETE /starbucks/orders/order?id 1234 H. Paik (CSE, UNSW) REST Week 6 32 / 54
Brief Recap of REST principles Connectedness/Links: Resources may contain links to other resources e.g., Order resource is linked to Payment resource In response to POSTing an order 201 Created Location: /starbucks/orders/order?id 1234 Content-Type: application/xml Content-Length: . order xmlns "urn:starbucks" drink latte /drink link rel "payment" href "/starbucks/payments/order?id 1234" type "application/xml"/ /order Both forward/backward links, when possible (e.g., order having ’cancel/delete’ link) H. Paik (CSE, UNSW) REST Week 6 33 / 54
REST Recap - Hypermedia H. Paik (CSE, UNSW) REST Week 6 34 / 54
REST Recap - Hypermedia H. Paik (CSE, UNSW) REST Week 6 35 / 54
REST Recap - Satefy, Idempotence H. Paik (CSE, UNSW) REST Week 6 36 / 54
Popular Resource Representation Formats XML (RSS, ATOM, .) Standard textual syntax for semi-structured data Managed within several standard tools like XML Schema, DOM, SAX, XPath, XSLT, XQuery, . animals dog name Rufus /name breed labrador /breed /dog dog name Marty /name breed whippet /breed /dog cat name "Matilda"/ /animals H. Paik (CSE, UNSW) REST Week 6 37 / 54
Popular Resource Representation Formats JSON (JavaScript Object Notation)2 Data interchange format derived from the JavaScript programming language for representing simple data structures (name/value pairs, arrays and other objects) Popularised by AJAX (Asynchronous JavaScript XML). { animals:{ dog:[ { name:’Rufus’, breed:’labrador’ }, { name:’Marty’, breed:’whippet’ } ], cat:{ name:’Matilda’ } } } 2 http://json.org/example.html H. Paik (CSE, UNSW) REST Week 6 38 / 54
One API for All One resource, multiple representations (it is the client’s choice): H. Paik (CSE, UNSW) REST Week 6 39 / 54
Building REST Web services In theory: REST does not require a specific client or server-side framework in order to write your Web services. All you need is a client or server that supports the HTTP protocol. choose a language of your choice you do not need a big server infrastructure (HTTP/Web servers are enough) e.g., In Java: You’d use servlets and override doGet(), doPost(), doPUT() and doDelete() URLs contains: servlet path path info (all you need to process a request in REST) You could use a third-party library for generating specific content type (CSV, JSON or XML, etc.) or use Strings concatenations for simple responses. H. Paik (CSE, UNSW) REST Week 6 40 / 54
Building REST Web services The basic pieces you need to create a RESTful service: a Path - the path to the service a request method (e.g., GET, POST) the response types from the service e.g., A quick look at a simple servlet that supports GET (and XML, CSV and JSON resource formats) A servlet is mapped to /places/sydney/* GET returns some interesting places in Sydney Default representation is XML, but other format can be added in the path info: JSON and CSV Uses http://www.JSON.org/java/index.html for the JSON encoding H. Paik (CSE, UNSW) REST Week 6 41 / 54
Building REST Web services H. Paik (CSE, UNSW) REST Week 6 42 / 54
Building REST Web services (Implementing an XML reply) H. Paik (CSE, UNSW) REST Week 6 43 / 54
Building REST Web services (Implementing a CSV reply) H. Paik (CSE, UNSW) REST Week 6 44 / 54
Building REST Web services (Implementing a JSON reply) H. Paik (CSE, UNSW) REST Week 6 45 / 54
Building REST services In reality . it would still be nice to have some support (a framework) Having a framework can help reduce boilerplate-type coding In Java, standard specification is: JAX-RS (http://jcp.org/en/jsr/detail?id 311) Apache CXF - http://cxf.apache.org/docs/jax-rs-basics.html Jersey - the JAX-RS Reference Implementation from Sun. RESTEasy - JBoss’s JAX-RS project. Restlet - probably the first REST framework, which existed prior to JAX-RS. H. Paik (CSE, UNSW) REST Week 6 46 / 54
Building REST services: JAX-RS http://java.dzone.com/articles/putting-java-rest JAX-RS uses Java annotations. Annotate your class with: @Path: to indicate the relative URI path you are interested in, @GET, @POST, @PUT, @DELETE, or @HEAD: to indicate which HTTP method you want dispatched to a particular method. @Produces: to indicate the response type 01. @Path("/orders") 02. public class OrderEntryService { 03. @GET 04. @Produces(MediaType.TEXT PLAIN) 05. public String getOrders() { return "There!";} 06. } Given “GET http://xxx.xxx.xx/orders”, JAX-RS would dispatch the HTTP request to getOrders() and return the content getOrders() produces. H. Paik (CSE, UNSW) REST Week 6 47 / 54
Building REST services: JAX-RS We may want to limit the size of the result set returned. “GET http://xxx.xxx.xx/orders?size 50” To extract this information from the HTTP request, use a @QueryParam annotation: 01. 02. 03. 04. 05. 06. 09. @Path("/orders") public class OrderEntryService { @GET public String getOrders(@QueryParam("size") @DefaultValue("50") int size) { . method body . } } @QueryParam will pull the “size” query parameter from the incoming URL The @DefaultValue injects the default value of ”50”. H. Paik (CSE, UNSW) REST Week 6 48 / 54
Building REST services: JAX-RS Exposing a single order as a resource: “GET http://xxx.xxx.xx/orders/1234” Using Path Parameters: 01. @Path("/orders") 02. public class OrderEntryService { 03. @GET 04. @Path("{id}") 05. public String getOrder(@PathParam("id") int orderId) { 06. . method body . 07. } 08. } To use @PathParam or @QueryParam: let’s not put resource identity within a query parameter when it really belongs as part of the URI path itself. H. Paik (CSE, UNSW) REST Week 6 49 / 54
Building REST services: JAX-RS Content-Type: the service produces HTTP response, so the content type must be set first. For example, let’s say our getOrders() method actually returns an XML string.: 01. @Path("/orders") 02. public class OrderEntryService { 03. @GET 04. @Path("{id}") 05. @Produces("application/xml") 06. public String getOrder(@PathParm("id") int orderId) 07. {. method body } 08. } H. Paik (CSE, UNSW) REST Week 6 50 / 54
Building REST services: JAX-RS JAX-RS understands the Accept header and will use it when dispatching. Content Negotiation: Accept: text/html,application/xhtml,application/xml;q 0.9,*/*;q 0.8 the client prefers: html or xhtml (q is 1 by default), raw XML second, and any other content type third 01. @Path("/orders") 02. public class OrderEntryService { 03. @GET 04. @Path("{id}") 05. @Produces("application/xml") 06. public String getOrder(@PathParm("id") int orderId) {.} 07. @GET 08. @Path("{id}") 09. @Produces("text/html") 10. public String getOrderHtml(@PathParm("id") int orderId) {.} 11. } “GET http://./orders/1234” with the above Accept would match getOrderHtml(). H. Paik (CSE, UNSW) REST Week 6 51 / 54
Building REST services: JAX-RS Content Marshalling: e.g., code to convert a list of orders to an XML string that the client can consume. The JAX-RS specification has some required built-in marshallers (e.g., JAXB annotated classes) @XmlRootElement(name "order") public class Order { @XmlElement(name "id") int id; @XmlElement(name "customer-id") int customerId; @Path("/orders") public class OrderEntryService { @GET @Path("{id}") @Produces("application/xml" public Order getOrder(@PathParm("id") int orderId) {. } @XmlElement("order-entries") List OrderEntry entries; . } JAX-RS sees the Content-Type (application/xml) and the JAXB annotated Order class and will automatically use JAXB to write the Order object to the HTTP output H. Paik (CSE, UNSW) REST Week 6 52 / 54
Building REST services: JAX-RS Response Codes and Custom Responses: HTTP spec defines what HTTP response codes should be on a successful request. (e.g., GET 200, OK; PUT 201, CREATED) JAX-RS returns the same default response codes. Sometimes, however, you need to specify your own response codes (or add specific headers or cookies to your HTTP response). @Path("/orders") public class OrderEntryService { @GET @Path("{id}") public Response getOrder(@PathParm("id") int orderId) { Order order .; ResponseBuilder builder Response.ok(order); builder.expires(.some date in the future); return builder.build(); } } H. Paik (CSE, UNSW) REST Week 6 53 / 54
Building REST services: JAX-RS Exception Handling: RuntimeException/WebApplicationException class It can take an HTTP status code or a Response object as one of its constructor parameters. @Path("/orders") public class OrderEntryService { @GET @Path("{id}") @Produces("application/xml") public Order getOrder(@PathParm("id") int orderId) { Order order .; if (order null) { ResponseBuilder builder Response.status(Status.NOT FOUND); builder.type("text/html"); builder.entity(" h3 Order Not Found /h3 "); throw new WebApplicationException(builder.build()); } return order; } } H. Paik (CSE, UNSW) REST Week 6 54 / 54
REST-based Web Services (I) Helen Paik School of Computer Science and Engineering University of New South Wales Resources: RESTful Web Services by L. Richardson and S. Ruby, O'Reilly . (or a service in our context) on the Web H. Paik (CSE, UNSW) REST Week 6 2 / 54.
Texts of Wow Rosh Hashana II 5780 - Congregation Shearith Israel, Atlanta Georgia Wow ׳ג ׳א:׳א תישארב (א) ׃ץרֶָֽאָּהָּ תאֵֵ֥וְּ םִימִַׁ֖שַָּה תאֵֵ֥ םיקִִ֑לֹאֱ ארָָּ֣ Îָּ תישִִׁ֖ארֵ Îְּ(ב) חַורְָּ֣ו ם
ISAN REST Web Services API Version: 1.4 June 3, 2015 ISAN REST Web Services API Scope ISAN Rest Web Services description Author Erica Ozonne Creation Date 7-Jun-13 Last Edition 3-Jun-15 by REGIS FLAD Distribution Public Revision History: Date Ver. Description Participants 07/06/2013 1.0 First draft Author: EPA
consume REST APIs, and those who implement REST services. Every server-side programming language offers a variety of open-source and commercial frameworks to implement REST services. Similarly on the client-side, because REST is a thin layer on top of the HTTP protocol, every SDK, whether native or web, can consume REST APIs out of the box.
and web services are related to each other, introduces the principles behind REST, explains how HTTP verbs are used in REST applications, explains the need for RESTFul web services while building PHP web applications, and introduces some frameworks and tools that can be used to work with REST in PHP. Chapter 2 takes a first look at REST with .
carl h. lindner college of business s s s rest rooms rest rest rooms rooms rest rest rest rooms rooms rooms rest rooms stairs 2375 conference 2215 collabor-ation room 2402 production stairs 2130 2230 seminar open student teaching lab open to below (courtyard) stairs courtyard stairs open to below (lecture hall)
Cisco Nexus 1000V for VMware vSphere REST API Plug-in Configuration Guide, Release 5.x 13 Using the REST API Plug-in Increase max-port via REST. Cisco Nexus 1000V for VMware vSphere REST API Plug-in Configuration Guide, Release 5.x 14 Using the REST API Plug-in Feature History for Using the REST API Plug-in.
Web service provisioning is the art of hosting and offering Web services from mobile devices, which actively contributes . REST-based: RESTful Web services gained much at-tention from the Web community due to their simplicity and scalability. Major Web services providers such as Google, Amazon, Yahoo, and eBay adopted the RESTful Web services .
5.3.3.5 Dana Pensiun Lembaga Keuangan 80 5.3.3.6 Pegadaian 84 5.3.3.7 Asuransi 85 BAB VI PASAR UANG DAN PASAR MODAL 93 6.1 Instrumen-instrumen Pasar Uang 95 1. Treasury Bills (T-Bills) 95 2. Bankers Acceptance 96 3. Bill of Exchange 98 4. Repurchase Agreement 99 5. CPPP (Commercial Paper Promissory Note) 101 vi
