Our team is currently looking at developing the interfaces for a new network monitoring system. We are to support access to the system from:
a web browser (Javascript/HTML5 based)
any REST client (could be a command-line REST shell or some other higher level system, for ex: to do mashups).
We were thinking of providing same REST endpoints at the Server side (Java EE based) to support both types of clients. This is because, we think a browser is also a REST client, in a sense. And because we thought it will avoid any duplication at the server-side. And we are running low on engineers (which may be a good thing after all!).
We will be doing Asynchronous request/response-handling at the browser using Ajax. And we think any other REST client needs to take care of any asynchrony it wants.
1) Is this how it is usually done these days ?
2) Is this a good approach, regardless of any other consideration?
Or does one need to consider any other aspect, before making this decision ?
3) I think this implies that we are to send all responses as JSON only from the server and do client-side rendering only. Right ?
Yoy're right! Here's my opinion:
1) Is this how it is usually done these days ?
Yes. The most of REST Api were builded on same server side API. This API provide information to the client, whatever is the client side, that must be an browser or command line call.
You can take a look on free Apigee ebooks, especially this one, to get more information about how to build a powerful Restful api.
2) Is this a good approach, regardless of any other consideration? Or does one need to consider any other aspect, before making this decision ?
I think is the finest approach, you have one api to manage your services to clients.
3) I think this implies that we are to send all responses as JSON only from the server and do client-side rendering only. Right ?
Right. Some javascript frameworks, like AngularJS, do all the rendering on browser only with JSON responses from the Rest Client. You can do it with JQuery as well.
Related
I am a bit confused about the difference between the two.
What I have been making till now is just deploying a web application that gets invoked by a URL and returns a response(json/XML) .
what I have read about rest web services
Its a way to communicate with web applications and to reveal your methods to the world.
Question 1
But in my case I did the same revealing the URL .
Platform independent
The rest features say that its Language-independent (C# can talk to Java)
Question 2
But in traditional approach also any language can invoke any web service by simple request (get/post) which ever implemented.
Question 3
What is rest and how to get started with it (specifically in terms of django) if possible.?
You are doing REST.
REST is not a library, or a format, it's simply a technique. What you call the "traditional approach" is exactly what REST is: simple requests via GET and POST (as well as PUT and DELETE) to an endpoint that returns JSON or XML.
That is in contrast to the previously-dominant way of making API requests, ie SOAP, which requires all sorts of up-front configuration of WSDL files and service discovery, along with particularly specified request formats.
I am working on a legacy Django site which is facing a rewrite to replace the existing Flex frontend with HTML5. Further down the line there will be a mobile app (iPad only at this point), which will require a RESTful API.
My question is how much extra work would it be (turnaround is short < 2 months) to implement the web front end in something like backbone.js/mustache talking to a RESTful API on the Django side (probably tastypie) - in comparison to writing it as a standard Django app and bolting on the API later? I'd prefer to go with the former, but just wondering if anyone has gone down this road and what issues you encountered.
IME, RESTful APIs keep the server side clean, thus easier to maintain and scale. Your data models suddenly make sense as you need only worry about CRUD actions - the client makes the necessary API calls, thus allowing your endpoints to return only one type of data/dataset.
Your routes can then become modular and its easier to keep things DRY.
However, reliance on client side JavaScript ultimately means more cross-browser consistency issues. Hope you made the right choice!
After going through the following article I came to know that if Axis2 is used on both ends, we could expect high improvements in performance.
Link : http://wso2.org/library/91
I'm writing code to consume a webservice. I'm just curious to know the framework used on the server side. How do I do it programatically using Axis2.
Server side you can use any java class.The following are the server side styles that axis provides.
Service Styles - RPC, Document, Wrapped, and Message
Also see the documentation here.
There is no such API available as such. Of course, such API is not supposed to be there at all. The whole point of using web services is interoperability i.e. the server doesn't care how the client is implemented and the client does not care how the server is implemented. Defining such an API does not make any sense, adds no business value except curiosity as in your case above.
Albeit, It still might be possible to do so, unofficially. Try to send some parameter value which is not correct business value. From the fault that is generated, it might also give stacktrace of the server through which you can probably guess the server side framework being used.
I am looking on advice on how best to approach a new project I need to develop. From the outset I must add, I have 0 experience with Web development on any level.
What I need to do is provide a web interface through the browser which will communicate with a server back end. The data retrieved will be sourced from either a DB or from another source - external device which the server itself will communicate with via IP. The data retrieved from the external device will always be a string format of n length (non unicode) and the DB data will mostly be strings and numbers with the odd blob thrown in (storing a picture). The communication will always go from the Client (web browser) to the Server. I don't believe that the server would need to instigate the comms.
I have Delphi XE, so started looking at using a REST server for communication and I think that seems to be OK. However, from what I can see, I need to create HTML web pages to "render" the data on the web browser. Is that true? Can I use the IW components with a REST server? If so, I'm not sure how to get the data to/from the browser UI. Am I better of investigating Ruby on Rails perhaps? From what I read on a different thread in here, it's based on MVC and some other areas which I feel, design wise, would fit how I would create the application (I was planning on creating the app based on the MVP or similar design pattern).
I think REST makes the most sense, so if the IW components can't be used, are there any 3rd party products I can use which would let me design "pretty" UI html. Given I don't know java script, would that be a stumbling block with REST too.
Thanks and hopefully I have provided enough information.
Thanks
Jason
Will a human being be responsible for typing the data retrieved from your external device into a web page?
If so, and you have no web development experience, Intraweb is definitely the way to go for Delphi programmers wanting to build a web application without learning new skills. For additional components to create a prettier UI I suggest using TMS Software's Intraweb Component Pack Pro.
If you don't need a human being to manually type in this data then you don't need Intraweb at all. Instead you would write a client application which presumably interrogated your external device for the data and then transmitted it to the REST server. Look at the documentation you've used to build your REST server and it should have a section on how to build a REST client.
You can build an ISAPI module with delphi that does the job, or include a HTTP server right into you executable with Indy, ICS or Synapse.
ISAPI will give you the freedom to choose Apache or IIS and give you all their power this way. Embeded HTTP server will give you a nice small application in which you control all ascpects of how it works.
Yes go with REST as it is simple and clean. All you need is to think and design the API (functions that your server will support). You can bind the APIs to the URL schema thus using the REST principle. I would do it simply like this.
A client makes a request. You show some form of GUI (load or render a HTML page with possible javascript)
User makes an action, you call appropriate API (or the user does it directly).
Show the user some result
Just guide the user process through a series of API calls until the result is made
You can use plain HTML and then add javascript if needed (jquery) or you can use ExtJS from Sencha which makes building a nice GUI a lot easier and is very well structured.
I would not use any "WYSIWYG" web tools. Plain old HTML written by your favorite editor is still the king in my opinion.
I see APIs such as PayPal, etc. offering to call their services using NVP or SOAP/WSDL. When using a .NET environment (3.5) using traditional web services (no WCF) which is better and why? I know WSDL lets you drop in the API URL and it generates the wrappers for you. So then why do companies even offer NVP?
There seems to be never-ending confusion in this industry about the different types of web services.
SOAP is a messaging protocol. It has as much in common with REST as an apple has with a lawn tractor. Some of the things you want in a messaging protocol are:
Headers and other non-content "attributes."
Addressing - routing of a message to different servers/recipients based on the headers;
Guaranteed delivery via queuing and other methods;
Encryption, signing, and other security features;
Transactions and orchestrations;
Accurate representation of complex structured data in a single message;
...and so on. This is not an exhaustive list. What WSDL adds to SOAP, primarily, is:
Discoverability via a contract, a form of machine-readable "documentation" that tells consumers exactly what is required in order to send a message and allows proxies to be auto-generated;
Strict, automated schema validation of messages, the same way XSD works for XML.
REST is not a messaging protocol. REST is a system of resources and actions. It is a solid choice for many architectures for several important reasons as outlined by other answers. It also has little to no relevance to "NVP" services like PayPal and flickr.
PayPal's NVP API is not REST. It is an alternative, RPC-like messaging protocol over HTTP POST for clients that don't support or have difficulty supporting SOAP. This isn't my opinion, it's a statement of fact. One of the fields in the NVP is actually METHOD. This is clearly RPC verbiage. Take a look at their API for UpdateRecurringPaymentsProfile and try to tell me that this makes a lick of sense to describe as a "resource". It's not a resource, it's an operation.
In the case of PayPal specifically, the "NVP" (HTTP POST) API is inferior to the SOAP API in almost every way. It is there for consumers who can't use SOAP. If you can use it, you definitely should.
And I'm not necessarily bashing PayPal for this, either. I know a lot of folks have bashed them for not putting together a "proper" RESTful API but that is not what I am getting at. Not every service in the world can be accurately described with REST. PayPal isn't really a resource-based system, it's a transactional system, so I can forgive their architects and developers for not having a perfectly elegant REST architecture. It's debatable perhaps, but it's not black-and-white. It's fine; I'll just use the SOAP system if I need to.
Compare this to, say, the Twitter API. This is a true REST service. Every "operation" you can perform on this API is accurately described as either the retrieval or submission of a particular kind of resource. A resource is a tweet, a status, a user. In this case it literally makes no sense to use a complex SOAP API because you're not really sending messages, you're not performing transactions, you're just asking for specific things, and these things can be described with a single URL. The only difference is that instead of getting an HTML web page back, you're getting some XML or JSON data; the way you request it is exactly the same.
A REST Web Service usually (always?) uses HTTP GET for the retrieval of some resource. And Twitter does exactly this. GET still uses "Name-Value Pairs" - that's the query string, ?q=twitterapi&show_user=true. Those bits after the ? are name-value pairs. And here's a great example of why you would want to use REST over SOAP; you can hook this up to an RSS feed and get streaming updates. I can turn it into a Live Bookmark in Firefox. Or I can download it in JSON format and bind it to something like a jqGrid. The interesting thing is not that the request uses "Name-Value Pairs"; the interesting thing is that it's a simple URL and can be consumed by anything that knows how to request a web page.
So to try and summarize all of what I've said, think of it this way:
Use a REST API (if available) when you want to expose data, or consume or publish it, as a permanent resource.
Use a SOAP API when the system is transactional in nature and/or when you need the advanced features that a complex messaging protocol can offer, such as RM and addressing.
Use an RPC API (which includes just about any API that's modeled entirely around HTTP POST) when there is no SOAP API or when you are unable to use the SOAP API.
Hope that clears up some of the confusion.
I assume that by Name Value Pairs, you mean REST services.
The benefits to REST are primarily ease of development, simplicity and elegance, and lower overhead (which is very important if you are sending and receiving a lot of small messages).
Here are some of the advantages of REST:
REST is more lightweight
Human readable results
Everything is a URI addressable resource
REST services are more easily cached
REST is easier to build (no toolkits are required)
REST is easier to call (HTTP - GET, POST, PUT, DELETE)
NVP is HTTP POST
name=fred
amount=100
code=403
etc
This is the default format from any HTML browser so it's simple to implement for sending data to a web service
I don't think it's a good format for receiving data from web service? JSON or XML would be more suitable
No everyone uses VisualStudio, or has access to automatic wrapper generators, or wants to use such a beast
Many web mashups are coded in Javascript, so using HTTP POST to send data is the simplest way. The return result is a standard HTML response code (200, 403, 500, etc) and/or some JSON
Many service providers offer multiple API's to cater for all customers