I am creating a rest api on java and I got a problem that users will have to poll my REST URL often to get changes in data. But then I think what if I will send them a special REST call to their server to notify for changes? It will be not a good api because they will have to have their procession points, etc. How to resolve this situation?
Perhaps you are not using the right tool for the job. REST over HTTP may not suit your needs.
Have you considered Server-Sent Events (SSE) or even WebSockets? They may fit your needs better.
Related
I have to write code to automatically create a JIRA based on some action performed in my workplace. The solution that my manager proposed is to create a JIRA creation agent. We are using REST architecture.
Last time I wrote a client. Now I have to write an agent. What I don't understand is the key and more like the technical difference between the two. Like how exactly these are different as for someone with very less experience with REST I feel hard to understand the core difference.
Do I have to code them in a different style? or what are some good practices to write these kinds of code?
I tried reading different blogs and related posts but couldn't find anything satisfactory to point out the differences.
This may be semantically different based on your company's internal linguistics, but typically it is as follows:
REST Server is the software which provides the API which is exposed
REST Client is the software which uses the REST Server's API to make requests and get the resulting information (usually JSON). This is more of an interface to make the requests
REST Agent uses the REST Client to make the requests but actually uses the resulting JSON and processes it to perform some sort of action
However colloquially people use REST Client and REST Agent interchangeably. The main thing is delineation of who is providing information with API and who is making requests for information through an API.
EDIT: In order to clarify in your case the agent would be making a request through the API but would most likely be a PUT or POST request to create a JIRA issue.
I am working on an application with a completely decoupled front and back end. The front end has been implemented using Angular and the back end is implemented in Java using Spring extensively. Communication between the two is done via a Spring-managed Rest API. In addition to this, we have an external third party application(s) that also use this Rest API. So the API is used for two purposes: (1) as a "generic" API for an indeterminate number of clients and (2) as a very specific API designed specifically to meet the requirements of the Angular front end. We have separate Controllers to handle the separate concerns.
The problem I ran into was that of CORS. At the moment I have just annotated the Controllers with #CrossOrigin and that is fine for now but, I would need a more secure solution before we go live. I am aware that you can specify certain domains to limit when cross origin requests are allowed, however, that would not work for me. It would work if we just had the Angular front end to consider, but what about the external clients? There domains are not known. I almost need some sort of mechanism for the clients to authenticate and register themselves at runtime and then only these registered clients will be allowed to perform Cross Origin requests.
So that is what I am asking: given the above, what is the best solution to my problem? I need a solution that protects against Cross Site Request Forgery as well as meets my requirements stated previously.
I am making a automation website to send multiple files to an another site to prevent filling form every time to send a file.
I want to to make the POST request from server, because AJAX doesn't allow request to other domains.
How I can make this?
I am using Spring MVC3
Use apache http components - it allows you to perform http requests. You can also use (without 3rd party libraries) new URL(..).openConnection(), but it's less pleasant to code with it.
You can use Apache HTTP Components to implement pretty much any HTTP calls you want in your application. Also, note that it is possible to do cross domain AJAX with certain helper technologies like Flash ... if you really needed too.
first poster :)
As the title says, I am looking to create a desktop app which will notify me of changes on facebook and new emails, and the facebook part (the first part I've tried) is baffling me. I've never worked with an api before, and have no idea how to integrate facebook's api with this desktop helper I want to create. I will be using java to create this desktop helper.
Thanks in advance!
Here are few pointers for you to get started. Please feel free to ask for clarifications and I will edit my answer accordingly:
For facebook, you can actually pull all those info via their API. There are a lot of types for API, but Facebook specifically use REST API over http.
To simplify, think of it as making an http call with specific parameters and you will be getting an output back.
In order to use facebook API you need to understand their protocol including authentication/login and how to request for things that you want. This would require some reading to their documentation which is pretty complete and available at http://developers.facebook.com/docs/.
For the description of their API URL and the input/output documentation, you could directly jump to Graph API Documentation http://developers.facebook.com/docs/reference/api/.
In order to call their API via HTTP from Java, you could leverage HttpClient library from Apache Http Components project http://hc.apache.org/. They have plenty of tutorial and examples for how to make http call using HttpClient
For combining with all other emails accounts (per your question), you need to deal with SMTP or IMAP (whichever email protocol that you are planning to combine with Facebook). This is already built-in to Java via their Java Mail API collection
You then can poll this data on interval basis to get an update from Facebook and your mails
Once you have figured out how to get the data, the rest is just following a good MVC framework. That means separating out your presentation, data and controller (application logic). Make sure that you are separating the classes for #1 and #2 and each of them put their data to normalized data format that then get feed to your View (presentation layer)
im starting with web services. I'm working in a project that needs to communicate Android with a web server and I'd like to save some time chosing the appropriate protocol for the communication.
Between JSON ,REST and SOAP:
Which ones can I run in a non-dedicated server?
Whats the best choice for a high trafic server?
Thanks in advance
JSON and REST are not mututally exclusive. JSON is a data format that the REST interface can return.
You may run either on a non dedicated server. I would personally choose REST for rapid prototyping on Android as it is easier to get up and running. (With SOAP you will probably want to have a schema which takes time to put together)
There's a good comparison between REST and SOAP on the REST wiki article: http://en.wikipedia.org/wiki/Representational_State_Transfer#Concept
REST is more of a framework than a communications protocol. JSON and SOAP could be use to create a RESTful application.
If you're writing something with many resources, I'd use REST as it is far more structured. There are also a lot of libraries that will set most of things up for you. I find JSON and SOAP are better for custom functionality that you want to hack together quickly. They can be lightweight, but less structured.