I am trying to create a RESTful web service that accepts JSON arguments and gives out a JSON response.
What I want is to accept HTTP requests made to my URL endpoint.
Something like,
POST /the/endpoint HTTP/1.1
Host: mywebsite.com
{"name":"yourname", "department":"your_department"}
Do a DB read at the backend and give relevant parameters like, say Manager name, salary etc as a JSON object, as the response.
What's the best way to go about it? I was thinking of using Java servlets for this? Is there a better way?
PS - I am just getting started so detailed answers or links to tutorials as to how to implement it would be much appreciated.
Thanks.
Yes you can easily do this with Servlets and some Json Libs for Marshalling /unmarshalling the Json Object to Java Object.
You can make use of Json libs like
Jackson ,
Gson etc
But you must know that REST application doesnt end with just handling the request and response , but it needs to take care of other non-functional requirements like
Authentication
Authorization
Security etc
Building this from a scratch from a Servlet is overkill and waste of time when there are ready made frameworks that these things for you
My favorite is Spring MVC 3.0
Check their project site for more details
Just to show you how easy to set up one in Spring MVC , check this below tutorial
Spring 3 REST Tutorial
Pls rate the post if it helps , Cheers.
If you want to go with Java, I suggest that you take a look at JAX-RS... And since REST is a complex topic, here is a url with tons of informations on it. http://code.google.com/p/implementing-rest/
As a complete beginner, I believe the best way to implement a (nearly) RESTful API without having to read a lot is simply to implement the API just using HTML pages and HTML forms with the back-end processing to handle them.
The rules are:
Use <a> tags to provide links to related resources. (navigation)
Use <form> tags to initiate any kind of processing operation on the server. (actions)
You can then make it properly RESTful by using progressive enhancement to add Javascript AJAX requests that perform PUT, PATCH, and DELETE instead of using POST for those three (of course, keeping POST for creating resources where the client doesn't know the resultant URI).
You can then click around and test the API in a web browser! Tools like Selenium can automate this.
If you need to provide JSON, this can be added after the API has been designed and tested, although libraries exist to process HTML or XHTML responses too, so JSON isn't necessarily required for machine readability.
if you are using php with symfony try:https://github.com/FriendsOfSymfony/FOSRestBundle this lets you create a real REST full servicer very quick.
Vogella made my day very easy when i started Web services with an super example here with eclipse screen shots ..Have a look here.
Related
this is a general 'what technologies are available' question.
My company provides a web application with a RESTful API. However, it is too slow for my needs and some of the results are in an awkward format.
I want to wrap their restful server with a proxy/adapter server, so when you connect to the proxy you get the RESTful API I wish the real one provides.
So it needs to do a few things:
passthrough most requests
cache some requests
do some extra requests on the original server to detect if a request is cacheable
for instance: there is a request for a field in a record: GET /records/id/field which might be slow, but there is a fingerprint request GET /records/id/fingerprint which is always fast. If there exists a cache of GET /records/1/field2 for the fingerprint feedbeef, then I need to check the original server still has the fingerprint feed beef before serving the cached version.
fix headers for some responses - e.g. content-type, based upon the path
do stream processing on some large content, for instance
GET /records/id/attachments/1234
returns a 100Mb log file in text format
remove null characters from files
optionally recode the log to filter out irrelevant lines, reducing the load on the client
cache the filtered version for later requests.
While I could modify the client to achieve this functionality, such code would not be re-usable for other clients (different languages), and complicates the client logic.
I had a look at whether clojure/ring could do it, and while there is a nice little proxy middleware for it, it doesn't handle streaming content as far as I can tell - the whole 100Mb would have to be downloaded. Also it doesn't include any cache logic yet.
I took a look at whether squid could do it, but I'm not familiar with the technology, and it seems mostly concerned with passing through requests rather than modifying them on the fly.
I'm looking for hints where I might find the correct technology to implement this. I'm mostly language agnostic if learning a new language gets me access to a really simple way to do it.
I believe you should choose a platform that is easier for you to implement your custom business logic on. The following web application frameworks provide easy connectivity with REST APIs, and allow you to create a web application that could work as a REST proxy:
Play framework (Java + Scala)
express + Node.js (Javascript)
Sinatra (Ruby)
I'm more familiar with Play, of which I know it provides utilities for caching you could find useful, and is also extendable by a number of plugins.
If you are familiar with Scala, you could have a also have a look at Finagle. It is a framework build be Twitter's infrastructure team to provide protocol-agnostic connectivity. It might be an overkill for REST to REST proxy, but it provides abstractions you might find useful.
You could also look at some 3rd party services like Apitools, which allows to create a proxy programmatically (in lua). Apirise is a similar service (of which I'm a co-founder) that intends to do provide similar functionalities with a user-friendly UI.
Beeceptor does exactly what you want. It plugs in-between your web-app and original API to route requests.
For your use-case of caching a few responses, you can create a rule. That way it shall not hit the original endpoint.
The requests to original APIs can be mocked, and you can inspect response
You can simulate delays.
(Note: it is a shameless plug, I am the author of Beeceptor and thought it should help you and other developers.)
https://github.com/nodejitsu/node-http-proxy is looking useful - although I don't yet know if it can stream process for transcoding.
I am a newbie with ExtJS 4. I am having problems understanding the implmentation for the "/" syntax for the URL in a Rest Proxy.
For example when using a REST type Proxy the URL config in many examples is just "/users".
I'm confused by this and can't seem to understand it's implmentation. I'm expecting to see an actual executable ".php" or such URL which I have used successfully in an Ajax Proxy. In other examples I see "app.php/users". I understand the php file which I expect but the "/users" part I don't understand. I've spent a few hours trying to find the answer for this but nothing I found has defined it for me.
I'm sure the explanation is very simple.
Thank You in Advance.
For the full explanation you should study up on REST.
Something like /users is standard usage for a REST HTTP request, it is not just ExtJS implementation. Specifically to answer your question, the reason no file extension is included is to denote that this is a logical url, i.e. there is not a physical users.xml file necessarily, instead it is dynamically generated using RESTful webservices.
In other words, you would need to set-up a RESTful webservice architecture to use this ExtJS proxy configuration.
The link above and this tutorial on implementing RESTful webservices with Java helped me alot.
EDIT:
I found a better tutorial (I think) here, also showing implementations in something other than Java.
Could anybody clarify the process of consuming aspx webservices in iOS? I have already tried JSON framework but now, need to create an app that consumes .net webservices in XML format. I need both to post some data to, and get data from the server. I already read about existing XML parsers for iOS that I found (here)
The question is do I need to do additional setup, like wrapping my query strings in SOAP or smth, in order to communicate with webserver? Would it be sufficient to use only one of mentioned libraries in the link or do I need additional stuff?
UPDATE: I found one tutorial on web (here) that demonstrates how to consume web services using Json-framework. Also, I found another one that demonstrates it using NSXMLParser (here). I'm not not very familiar with WSDL and SOAP, so any detailed explanation on how to implement would be desirable :). In both of these examples you just have to construct a request string in xml format and execute it, and that's it. Both examples actually bypasses the heavyness of SOAP and WSDL, so I was wondering do I have to know and do more that just construct a request string, execute it and get response?
While wsdl2objc is out there (as noted by #Girish Kolari), the truth is that there's no easy answer. I've never successfully gotten wsdl2objc working well for something that I couldn't have done more easily by hand. You will need to learn SOAP and WSDL. That's just a fact of life if you can't get access to a REST interface. In my experience, your best bet for simple SOAP access is to do it by hand, and your best bet for somewhat complicated SOAP access is gSOAP. Your best bet for very complicated access is to redesign something so it's not so complicated, ideally in REST. SOAP is a giant pain that some languages (C#) shield you from. ObjC does not shield you from it, so it continues to be a giant pain.
Yes, SOAP leaves a bad taste in my mouth.
I have been reading about REST and SOAP, and understand why implementing REST can be beneficial over using a SOAP protocol. However, I still don't understand why there isn't the "WSDL" equivalent in the REST world. I have seen posts saying there is "no need" for the WSDL or that it would be redundant In the REST world, but I don't understand why. Isn't it always useful to programmatically bind to a definition and create proxy classes instead of manually coding? I don't mean to get into a philosophical debate, just looking for the reason there is no WSDL in REST, or why it is not needed. Thanks.
The Web Application Description Language (WADL) is basically the equivalent to WSDL for RESTful services but there's been an ongoing controversy whether something like this is needed at all.
Joe Gregorio has written a nice article about that topic which is worth a read.
WSDL describes service endpoints. REST clients should not be coupled to server endpoints (i.e. should not be aware of in URLs in advance). REST clients are coupled on the media-types that are transfered between the client and server.
It may make sense to auto generate classes on the client to wrap around the returned media-types. However, as soon as you start to create proxy classes around the service interactions you start to obscure the HTTP interactions and risk degenerating back towards a RPC model.
RSDL aims to turn rest like a hypermedia, in other words, it has more information than a service descriptor like WSDL or WADL. For example, it has the information about navigation, like hypertext and hyperlinks.
For example, given a current resource, you have a set os links to another resources related.
However, i didn't find Rest Clients that supports this format or Rest Server Solutions with a feature to auto generate it.
I think there is a long way for a conclusion about it. See the HTML long story and W3C vs Browsers lol.
For more details about Rest like Hypermedia look it: http://en.wikipedia.org/wiki/HATEOAS
Note : Roy Fielding has been criticizing these tendencies in Rest Apis without the hypermidia approach: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
My Conclusion : Now a Days, WADL is more common that Rest and Integration Frameworks like Camel CXF already supports WADL ( generate and consume ), because it is similar to WSDL, therefore most easy to understand in this migration process ( SOAP to REST ).
Let's see the next chapters ;)
Isn't it always useful to programmatically bind to a definition and
create proxy classes instead of manually coding?
Agree wholeheartedly, this is why I use Swagger.io
Swagger is a powerful open source framework backed by a large
ecosystem of tools that helps you design, build, document, and consume
your RESTful APIs.
So basically I use Swagger to describe my models, endpoints, etc, and then I use other tools like swagger-codegen to generate the proxy classes instead of manually coding it.
See also: RAML
There is an RSDL (restful service description language) which is equivalent to WSDL. The URL below describes its practice http://en.wikipedia.org/wiki/HATEOAS and http://en.wikipedia.org/wiki/RSDL.
The problem is that we have lots of tool to generate code from wsdl to java, or reverse.
But I didn't find any tool to generate code from RSDL.
WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate
However, REST uses the network protocol by using HTTP verbs and the URI to represent an objects state.
WSDLs tell you at this place, if you send this message, you'll perform this action and get this format back as a result.
In REST, if I wanted to create a new profile I would use the verb POST with a JSON body or http server variables describing my profile to the URL /profile
POST should return a server-side generated ID, using the status code 201 CREATED and the header Location: *new_profile_id* (for example 12345)
I can then perform updates changing the state of /profile/12345 using the HTTP verb POST, say to change my email addresss or phone number. Obviously changing the state of the remote object.
GET would return the current status of the /profile/12345
PUT is usually used for client-side generated ID
DELETE, obvious
HEAD, gets the status without returning the body.
With REST it should be self-documenting through a well designed API and thus easier to use.
This is a great article on REST. It really help me understand it too.
WSDL 2.0 specification has added support for REST web services too. Best of both worlds scenario. Problem is WSDL 2.0 is not widely supported by most tools out there yet. WSDL 2.0 is W3C recommended, WSDL1.1 is not W3C recommended but widely supported by tools and developers.
Ref:
http://www.ibm.com/developerworks/library/ws-restwsdl/
The Web Application Description Language (WADL) is an XML vocabulary used to describe RESTful web services.
As with WSDL, a generic client can load a WADL file and be immediately equipped to access the full functionality of the corresponding web service.
Since RESTful services have simpler interfaces, WADL is not nearly as necessary to these services as WSDL is to RPC-style SOAP services.
I'm creating an iPhone app and I want the app to be able to send some information in the form of JSON string over a web server/app (I really don't know) and display it in a web page or save it to a file. I know how to send the request from the iPhone, the problem is I don't have a clue on how to implement the server side and integrate it with a web page that can respond to the HTTP post I'm trying to send to it. I don't need any specific details so if you could only point me to the right direction e.g. reading material, websites, key technologies for this.
Thank you for your help
The general term for using JSON and HTTP is RESTful (actually that's not quite true, as REST doesn't technically mean JSON [though often it does!] and REST also includes other things, but it's still a good search term).
Here's a general set of links about the right kind of areas.
For python:
http://www.freenet.org.nz/dojo/pyjson/
For C#:
http://www.techbubbles.com/wcf/rest-based-wcf-service-in-aspnet-35/
For Java:
http://www.oracle.com/technetwork/articles/javase/index-137171.html
That should be enough to get you started; googling based on the various terms will throw up more articles. If you find any really good ones do add to your own answer!