I'm an experienced client application developer (C++/C#), but need to come up to speed quickly on writing server side code to perform RESTful interactions. Specifically, I need to learn how to exchange data with OpenSocial containers via the RESTful API.
The RESTWiki is a very good resource and then there is the classic "How I explained REST to my Wife".
However, don't forget to go read about it directly from the source, it is not as difficult a read as it may first seem.
And I am assuming you will be doing REST over HTTP so this will come in very handy.
Lastly, considering OpenSocial supports the Atom Publishing Protocol, this will be useful.
Enjoy.
RESTful Web Services
I found this this to be a good introduction to RESTful web apps, although it doesn't refer to OpenSocial containers.
Related
I hear people say as per Roy Feilding that REST is not just for web services. If so, what other systems/mechanisms/anything can use it?
The REST interface is designed to be efficient for large-grain hypermedia data transfer -- Fielding, 2000.
REST is intended for long-lived network-based applications that span multiple organizations -- Fielding, 2008
The problem, of course, is that if that's what you need -- the web is sitting right there, so in most cases it's going to be more practical to adapt to the web as is, and perhaps extend it a little bit in a useful direction.
The alternative requires not only re-inventing the wheel, but also persuading the world to adopt the new standard and use it.
Any system that has some type of access to the server, can even be an onboard system that has access to the API network
Any system that uses URIs to communicate information would be able to use REST.
Example: a theoretical database that fully follows REST rules.
Example resource "serverhost/database/table/1"
I've been reading around trying to understand what RESTful API is all about. I guess I understood the general outlines and a bit about how it's related to HTTP and all that.
In fact, one of the jobs I recently applied for required a 'must' knowledge of a RESTful API!! The job description was messy anyway and seemed it had been written by an HR person, or somebody who didn't actually have an advanced technical knowledge.
I fail to see how, as a frontend developer / UI/UX designer, I could benefit from the vague RESTful API stuff? What's the connection?! Should really be bothered?
Thanks!
Simple and Precisely NO.
For only a front End Developer; it is not necessary, it is must (or SOAP bases API) for BackEnd Application Developer.
I am Android app Developer, made REST api for my app and my friend is just working on Web Page UI for that APP.!
Ajax calls are little to know for you.!
But one should know little bit about APIs, it never hurts :)
RESTful api, and web services in general, are a way to abstract back ends from front end developpers. It allows front-end developpers to do their interfaces without the need to code any server-side logic.
Web services contain all the business logic. As a front-end developper, you'd need to know how to interact with such services, but the whereabouts of the api call are not required of you to understand.
Finally, it's a way to define clear separation between what the application looks like and what the application does.
REST is a way to think applications. To make short, the client is stateless and you use HTTP methods for what they are designed to in order to interact with your server resources. You also leverage HTTP status codes, media types, content negotiation (Conneg).
If you want to know more about principles of RESTful services and Web API, you could have a look at this link: https://templth.wordpress.com/2014/12/15/designing-a-web-api/.
Hope it helps you,
Thierry
From client perspective the two main differences between REST and other e.g. SOAP webservices, that you have to use stateless communication (so you won't have a server side session, login, logout, etc...) and you have to use hyperlinks as request templates instead of building request from scratch. Because of these constraints your client breaks much harder by API changes.
I'm really confused everytime I come around this question, what characteristics would help one choosing SOAP over REST or the other way around?
I mean, besides the fact that REST has a compact format compared to SOAP, and the other "minor" or "technical" differences, what are the "obvious" differences that make one of them more suitable for a project and not the other?
Just for the record, I have read all of the other questions (1|2|3|4) regarding this matter on Stack Overflow, and not one of them answered my question.
The difference between REST and SOAP is fundamental, yet they're not that dissimilar. Ultimately, you still need to transfer exactly the same information in order to perform a particular abstract operation. It's entirely easy to make REST rather low-performing by choosing poorly what information to return, and SOAP with MTOM can transfer large binary chunks efficiently. There's even the possibility to use non-XML encodings and connected transports (e.g., XMPP) with SOAP that can make it more efficient than REST.
So don't worry about that!
A much more relevant thing to think about is that SOAP continues to have significantly more advanced tooling support in some languages, and that other languages strongly prefer REST. For example, if you want a Java client for your service, you'll be able to get going with SOAP in minutes: just put the WSDL location through a tooling engine and you've got yourself a basic client. On the other hand, if you're working with a Javascript client then you'll absolutely prefer to deal with the REST interface; Javascript works great with REST.
A key thing to note here is that you can have your service support both SOAP and REST at once (you might need to put them on different endpoints, but that's not very onerous). I do this with a service I support (using Java and Apache CXF) and the overhead of doing both is minimal: the key is that I need a clean abstract interface behind the scenes that both the SOAP and REST interfaces use.
If you just want a simple, visual guide to help you measure SOAP and REST against your applications requirements...
Vijay Prasad Gupta has put together a simple, helpful flow-chart.
Direct link to flow chart:
https://drive.google.com/file/d/0B3zMtAq1Rf-sdVFNdThvNmZWRGc/edit
Link to article:
https://www.linkedin.com/pulse/20140818062318-7933571-soap-vs-rest-flowchart-to-determine-the-right-web-services-protocol-for-your-needs
SOAP is a form of RPC and REST is architecture style that can scale with the web.
REST concerns about the following (copied from RESTful Web Services)
Addressability
Statelessness
Representations
Links and Connectedness
The Uniform Interface
Two great books on REST and have some discussions on the topic that you are interested in.
REST in Practice
Restful Web Services
There are now REST apis for Mongodb and redis.
I can connect to those databases with my language's driver.
Or I can use the REST api. I understand that the REST api is easier to grok, and easier to convert from language to language. But there's less features.
But is there any reason to use the rest api if I'm already doing fine with the language driver?
Thanks.
In my opinion a RESTful API is useful when you have to integrate multiple different clients in heterogenous environments. It's also good when you need features that are already solved for HTTP – like caches or load-balancing.
REST resources are supposed to capture use-cases of your application. I find it highly unlikely that an API to a database would do that for you. Mostly like the native language driver is the appropriate choice.
Rich web clients can talk directly to it, without any server side mediator. Also, for instance, if you have a JCR repository with NoSQL connector on hostA and NoSQL store on hostB, you're glad for RESTful api.
In relation to this question, I have a follow up question that I am still confused over. I have been asked to compair REST vs Web Services. From what I have learnt about REST, it is not a web service, therefore how can you compair the two? What does the question mean when it says REST in this respect?
REST is an architectural pattern for web services emphasizing the usage of URIs as resources with a small set of operations that may be performed on them (usually PUT, POST, GET, and DELETE). I'm guessing you are being asked to compare REST to the ws* standard web services which utilize a lot of other technologies (including SOAP, though SOAP itself is not a web service, it is just a protocol that happens to be used in ws* web services).
REST can be used to provide web services just like databases can be used to store names and addresses. REST is far more general purpose than simply a way of providing a web API.
REST is useful for building distributed systems. However, many people use Web Services (note the capitals, this usually denotes SOAP, WS-*) for building distributed systems.
Wow, I just saw the homework tag. That is one seriously mean question. There are industry veterans who could not come close to answering this question.
A more accurate question would be: Compare REST using HTTP versus RPC using SOAP for building distributed systems.
They probably mean REST verse SOAP. They're all web services in concept.
The abbreviation REST stands for "REpresentational State Transfer".
REST APIs are used to call resources and allow the software to communicate based on standardized principles, properties, and constraints. REST APIs operate on a simple request/response system. You can send a request using these HTTP methods.
Hence REST is just an API (an interface that allows you to build on the data and functionality of another application) architectural style.
On the other hand, web service is a network-based resource that fulfills a specific task. Yes, there's overlap between the two: all web services are APIs, but not all APIs are web services.