I'm new to web development. Reading the Facebook Graph API documentation, I found it quite interesting to use a unique URL for data query and Json for sending the data.
My question is: what's the name of this technology? I have worked with RPC and RMI in C and Java but this one is new to me. I want to learn more about it.
It is called REST or at least it is perceived as such. Traditional REST differs a lot - the facebook API is actually an RPC-over-HTTP API, but such APIs are now commonly called RESTful, although they are not, by definition.
Related
We are using SOAP based web services to let end user schedule service appointments. Our portal is WebService client & we have a number of Vendors(who are spread across the globe in various timezones) who are building Webservice Server operations.
We are thinking to build it as a contract first SOAP based web services so that we have tight control(interface based e.g. date-time format should be standard xsd:dateTime etc.) over what can be sent & received as part of XML messages for possible success & error scenarios(via different error codes). We want to keep single client code for all the vendors. We would like to determine
1) Should we think about using RESTful web services?
2) Is there any way the vendors can use RESTful services also if they want at their end(by sticking to our WSDL contract) & we use SOAP at our end
First a little bit about,
REST (Representation State Transfer) is an architecture style to develop webservice. In which data and functionality are considered as a resource and can be accessed via URI (Uniform Resource Indicator). It follows client server architecture and uses stateless protocol (usually HTTP). Typically in REST webserivces resources are acted upon by GET, PUT, POST,DELETE operation. Generally we use JSON to exchange data between client and server. It is light weight.
On the other hand SOAP (Simple Object Access Protocol) is a XML based mesaage protocol. Which is generally used on enterprise level to define their own interfacing and operations as services. It also follows REST architecture.
So basically, it is a RESTful webservice.
Now to answer your question,
It seems you are going to expose your webservice client on enterprise level. Which is going to be used by many vendors to implement their own webservice server.
So, it is perfect, you go with SOAP webservices.
You will define the skeleton of the webservice like Message formats, Operations, binding etc which is called WSDL. It is widely used standard and very easy to understand by any third party. Something called WADL is used for REST services also but it is not very user friendly.
The same contract (WSDL) will be used by your vendors to implement the webservice on their server in Top to Bottom approach using some API, for example JAX-WS.
This way you will have a tighter control over your operations, formats, security etc. in a single contract (WSDL).
Now if a vendor wants to use REST webservice instead of SOAP. You can build a JAVA proxy on top of your client. Which will convert your soap messages into REST to send/receive request/response to REST webservices. But you can not dictate your contract in this approach. Although, You can recommend vendors to build their own proxy to handle your SOAP webservice requests. This way your contract will be intact.
If you are going to expose your webservice client for small applications then it is alright to go with REST but if you are an enterprise and going to expand in future, you should go with SOAP for robust features and easy maintenance.
Disclaimer: please do not consider this answer as really serious.
Well, I think question too abstract. Why do you asking it? Because you see yourself that currently everything is RESTful? Then you'r right. You can do any protocol. But if you will do REST with JSON instead of XML, everybody will thank you. And if you will use 40 years old technology for creating modern service, then probably not. Same for your contractors.
The only advantage SOAP seems to have in your situation is that it is already implemented.
SOAP is a complex standard with unfriendly implementation and verbose implementation - i.e. hard to work with and maintain. Also note that you are not even using it "by the book" since your security is external to it and not using ws-security
REST based interfaces would make your and your users' lives easier. I suggest you take a look at standards and tools like swagger for building APIs.If you're running on premise you can take a look at API gateways like tyk If you're running in the cloud you also take a look at AWS API Gateway
Now I am creating an iOS application. I also implemented some web services. My requirement is : "The user should be able to call a web service API by Sending a Text Message(SMS)". After a lot of research I found out that there a provider called Clickatell(http://www.clickatell.com/). But I don't know how can I configure it? Please help me in configuring this. Or Is there any other APIs or SMS gateways providing this service?
Disclaimer, I do developer evangelism part time at Nexmo.
Here are a few SMS APIs that I've used (I've not really used Clickatell, but I've gone through the signup process, and the following APIs seem a lot simpler to use):
Nexmo
Twilio
Tropo
All three APIs are straight forward REST/HTTP APIs.
You can call the API directly from your mobile application, however, you should consider if you really want to then compile your API credentials into your application. It may be better to host a kind pf proxy that your application uses - here's some example code used as a verification service, but it's essentially the same concept: https://github.com/Nexmo/Verify
I would suggest to take a look at Mogreet's new Developer Web Site
Very easy to use REST/HTTP APIs and very powerful. It supports sending SMS/MMS with awesome quality for all media types.
The Graph API documentation says that the (invite only) message API endpoint is read-only.
The MyPad iPad app allows users to both read and compose messages.
Facebook has two APIs at present. The Graph API, which is what all developers should be using, and the REST API which they are in the process of depreciating. While they advise people to use the Graph API, it still lacks features found in the REST API. One of these would appear to be the ability to send messages. Details on the REST API can be found at their documentation page
Neither graph nor rest API can be used to send inbox messages to any user.
Mypad uses the other way around, which use m.facebook to compose and send(POST) messages directly.
of cos, it requires massive understanding of m. site of facebook. And problem is expected when facebook modify any structure on their m.site one day.
What is the difference between OData and REST-ful web services?
UPDATE Warning, this answer is extremely out of date now that OData V4 is available.
I wrote a post on the subject a while ago here.
As Franci said, OData is based on Atom Pub. However, they have layered some functionality on top and unfortunately have ignored some of the REST constraints in the process.
The querying capability of an OData service requires you to construct URIs based on information that is not available, or linked to in the response. It is what REST people call out-of-band information and introduces hidden coupling between the client and server.
The other coupling that is introduced is through the use of EDMX metadata to define the properties contained in the entry content. This metadata can be discovered at a fixed endpoint called $metadata. Again, the client needs to know this in advance, it cannot be discovered.
Unfortunately, Microsoft did not see fit to create media types to describe these key pieces of data, so any OData client has to make a bunch of assumptions about the service that it is talking to and the data it is receiving.
The OData protocol is built on top of the AtomPub protocol. The AtomPub protocol is one of the best examples of REST API design. So, in a sense you are right - the OData is just another REST API and each OData implementation is a REST-ful web service.
The difference is that OData is a specific protocol; REST is architecture style and design pattern.
REST is a generic design technique used to describe how a web service can be accessed. Using REST you can make http requests to get data. If you try it in your browser it would be just like going to a website except instead of returning a web page you would get back XML. Some services will also return data in JSON format which is easier to use with Javascript.
OData is a specific technology that exposes data through REST.
If you want to sum it up real quick, think of it as:
REST - design pattern
OData - enabling technology
In 2012 OData underwent standardization, so I'll just add an update here..
First the definitions:
REST - is an architecture of how to send messages over HTTP.
OData V4- is a specific implementation of REST, really defines the content of the messages in different formats (currently I think is AtomPub and JSON). ODataV4 follows rest principles.
For example, asp.net people will mostly use WebApi controller to serialize/deserialize objects into JSON and have javascript do something with it. The point of Odata is being able to query directly from the URL with
out-of-the-box options.
From the OData documentation:
The OData Protocol is an application-level protocol for interacting with data via RESTful web services.
...
The OData Protocol is different from other REST-based web service approaches in that it provides a uniform way to describe both the data and the data model.
OData (Open Data Protocol) is an OASIS standard that defines the best
practice for building and consuming RESTful APIs. OData helps you
focus on your business logic while building RESTful APIs without
having to worry about the approaches to define request and response
headers, status codes, HTTP methods, URL conventions, media types,
payload formats and query options etc. OData also guides you about
tracking changes, defining functions/actions for reusable procedures
and sending asynchronous/batch requests etc. Additionally, OData
provides facility for extension to fulfil any custom needs of your
RESTful APIs.
OData RESTful APIs are easy to consume. The OData metadata, a
machine-readable description of the data model of the APIs, enables
the creation of powerful generic client proxies and tools. Some of
them can help you interact with OData even without knowing anything
about the protocol. The following 6 steps demonstrate 6 interesting
scenarios of OData consumption across different programming platforms.
But if you are a non-developer and would like to simply play with
OData, XOData is the best start for you.
for more details at http://www.odata.org/
ODATA is a special kind of REST where we can query data uniformly from URL.
REST stands for REpresentational State Transfer which is a resource based architectural style. Resource based means that data and functionalities are considered as resources.
OData is a web based protocol that defines a set of best practices for building and consuming RESTful web services. OData is a way to create RESTful web services thus an implementation of REST.
I'm going to be developing a REST-ful Web Service for a new public website. The idea behind the web service is to have 3rd parties develop fully functional UIs for the business logic.
For security reasons, I'd like to avoid users having to give their passwords for our service to the 3rd party applications. (Perhaps this shouldn't be a big concern?) Instead, I'm looking to implement some sort of login system on our site that provides an auth token to the 3rd party app but keeps the actual password out of their hands.
This made me think that OpenID might be a potential solution here. It seems to me that it should work: the actual password is handled by the OpenID provider and so it doesn't rest with the 3rd party app. I think that the trouble would probably lie with the various passthroughs, but that should be manageable.
However, there's a surprising lack of Googleable info on this, so I'd like SO's opinion. Has anyone implemented a similar system before? Is it even possible? Is it worth the trouble?
I agree completely that what you want is OAuth; I say that having worked on both OAuth and OpenID systems. I've also been in your boat a few times, having to develop a REST web service api.
For a really good ideas on OAuth, and why it is what you want see these attached article:
These are must read, there are four parts read them all:
http://hueniverse.com/oauth/guide/
the RFC, read after reading above as it can be a little daunting for most:
http://oauth.net/core/1.0
And then finally maybe some code. I have a couple projects hosted that are using Java/Groovy to do OAuth. One is a plain old OAuth client, the other is a client for specific interactions with NetFlix.
http://www.blueleftistconstructor.com/projects/
If you are relatively inexperienced with REST (you haven't built a full scale web api yet) I would recommend that you buy (or better get your boss to) "RESTful Web Services" by Richardson & Ruby. It is an O'Reilly book. I can say that it is one of their better books to debut in the past few years.
It might also help to look at some RESTful OAuth based APIs. The NetFlix API is a perfect example: http://developer.netflix.com/docs
Good luck and happy coding!
So far, I've found 1 worthwhile link:
http://markmail.org/message/utf7js473zqv45hv
This conversation mentions something called "OpenID Exchange" which is right up my alley... but the included link is broken and there's not much solid information on Google for it.
Looks like OAuth might be the ticket: http://oauth.net/
We have been working on a project to integrate OpenID Authentication for SOAP web services. You can find our project at http://code.google.com/p/ws-sandhana/.
You can provide Single Sing On to your web services using OpenID authentication and you can enforce the trusted OpenID Providers and required attributes of the users by defining service security policies.
This is an open source implementation on Apache Rampart which is the security module for Apache Axis2 web service engine. You can find our blog at http://sandhana-project.blogspot.com/ for more information.