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.
Related
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.
I'm spending sometime with DynaTrace.
I'm impressed by its feature related to cross jvm instrumentation.
In simple words, DynaTrace is able to instrument Java code creating trace with some statistical information. This is nothing new.
There is a feature really interesting: when a call to an external JVM is execute, DynaTrace is able to link this new trace to the caller one (i.e. remote session bean, web services, remote RMI and so on).
How could it be possible?
I'm not able to immagine how to implement this feature? Any ideas?
Thank you
Dynatrace actually doesnt rely on information from beans. As you correctly said in your questions - we are using Byte Code Instrumentation such as other tools in the market as well. We instrument key methods of certain frameworks, e.g: Servlet, Axis, JMS, JDBC, ...
In the scenario where you make a call from one JVM to another using e.g: HTTP-based communication we instrument both the sending side of the HTTP Request as well as the receiving side on the other JVM. On the sending side we attach an additional HTTP Header with the ID of the current PurePath. PurePath is our patent technology. So - every PurePath (=every single transaction) gets a unique ID. This ID "travels" with the request, e.g: we put it on the HTTP Request as an HTTP HEader. ON the receiving side - your second JVM - we inspect that HTTP HEader and therefore know that all the data we collect belongs to that PurePath. This allows us to do real end-to-end tracing without relying on things like Beans or without correlating this data based on e.g: timestamps
Makes sense?
If you have more questions let me know. I also recorded some videos and put on YouTube to explain the technology and the product itself: http://bit.ly/dttutorials
This information is normally extracted using MXBeans. Such beans provide a standard API for accessing standard runtime information. Similarly, such applications often scan the class loaders for specific classes and extract relevant information by hard-coded access. This is why less popular solutions are often not supported by monitoring tools.
I have read lot a whats are difference b/w soap and restful web services. I have got specific doubts for which i did not get answers. Here they are :-
What goes in favor of Restful web services
In nutshell everybody seems to be preferring Restful web services over soap. main reason behind it easy to develop and understand. Also faster mainly because of light weight data exchange format like json. Also in Performance in restful web services is better because less data is traveled over network(Soap involves extra layer of saop message under http request). So far so good.
Accepted answer at how is Restful web services better than SOAP based webservices also says
REST naturally fits for Web/Cloud API's, whilst SOAP fits for
distributed computing scenarios.
I did not get whats the difference between Web and distributed computing scenarios. Web is also case of distributed computing scenarios. Is n't it ? so how come one is better for web while another is for distributed scenarios ? (Q1)
What goes in favor of SOAP :-
Same answer also says that SOAP caters for stateful operations. As per my understanding its not true. If you need to maintain the state you need to maintain thru you code like sending some unique ID in both request/response that relates them Is n't it? (Q2) If thats the case that can be done in restful web services also.
Some says SOAP is better in terms of security. I don't what security soap provides that rest does not? (Q3)
Soap is probably is better in one sense that it has WSDL(that too generated by tools) doc thru which clients can generate their respective stubs. In restful webservices developer has to create the comprehensive doc himself so that client knows about the input request parameters. correct ? (Q4)
Note :- I have referred Q for question(Q1 is Question1)
There are 3 reasons to prefer REST over SOAP
Resources have URLS that identify them. If you want to share the result of some API operation with a friend, then you don't have to instruct them verbally on which API method to call and which parameters to pass. Instead, you can just share with him the URL. (for safe operations only). A great example is restaurant sites that are built in flash. If you just want to share with a friend the menu of the restaurant, you can't do that very easily. You can only tell him which buttons to press when the flash page loads.
With REST you can take advantage of the existing HTTP infrastructure on the internet to do a lot of work, i.e. caching, resource conflict management, and so on. You don't have to reinvent the wheel.
Related to #2, many developers are already used to working with REST architectures. If you use REST you significantly cut down on the learning curve that new devlopers will have to incur when learning how to use your service.
REST is cache-able for GET request. For SOAP, when using HTTP as the transfer mechanism, is sent via HTTP POST requests which are not cache-able.
I'm working for a company and they require me to code an Android application that will handle sensitive data stored on a centralized database (MySQL), so I need to code a web service to communicate the Android app with the DB, and since in that connection will flow sensitive data I need to use a secure connection for that.
So, I decided to use json-rpc for the commucation, that's why I'm looking for two json-rpc implementations: the server-side in PHP (actually the hosting that they have is running PHP 4.3), and client side in Java (Compatible with Android) compatible between them and with SSL support.
I'm sure someone might make some suggestions, but this probably isn't the best venue to get help with library selection.
If, on the other hand, you ask concrete questions about certain libraries/implementations you might get intelligent answers. A common problem with that approch is that the asker doesn't know what questions to ask! (And that leads to re-inventions of wheels and commonly, poor decisions around security).
The JSON-RPC (1.0/1.1/2.0) group of protocols are extremely simple. There are hundreds of PHP implementations. I don't know much about evaluating Android libraries but this prior SO question gives a suggested client-side implementation for Android.
I'll primarily deal with the server-side part of your question by giving you concrete answers you can ask about a particular implementation you might be evaluating.
Considerations for the server-side PHP JSON-RPC implementation:
How will you handle transport authentication?
How will you handle RPC-method authorization?
How will you handle transport security?
Will you need to handle positional/named/both style method arguments
Will you need to handle/send notification messages?
Will you need to handle batch requests? Will you need to send batch responses?
How does the PHP implementation behave under a variety of exception/warning conditions?
How does the PHP implementation advise against or mitigate the PHP array set/list duality?
Will you need to implement SMD?
Will your web-service also need to perform other HTTP-level routing? (e.g: to static resources)
How will you handle transport authentication?
Assuming you use HTTP as the transport-layer protocol, how will you authenticate HTTP requests? Will you use password/HTTP-auth/certificate/SRP/other authentication? Will you continue to trust an open socket? Will you use cookies to extend trust after authentication?
These aren't really JSON-RPC related questions, but many server-side implementations make all sorts of assumptions about how you'll do authentication. Some just leave that entirely up to you. Your choice of library is likely be greatly informed by your choices here.
How will you handle RPC-method authorization?
You might decide that once a user is authenticated that they're allowed to call all exposed methods. If not, then you need a mechanism to allow individual users (or groups of them) to execute some methods but not others.
While these concerns live inside the JSON-RPC envelope, they're not directly addressed by the JSON-RPC protocol specifications.
If you do need to implement a method-"authorization" scheme, you might find that some server implementations make this difficult or impossible. Look for a library that exposes hooks or callbacks prior to routing JSON-RPC requests to individual PHP functions so that you can inspect the requests and combine them with authentication-related information to make decisions about how/whether to handle those requests. If the library leaves you to your own devices here, you'll likely have to duplicate lots of user/method checking code across your JSON-RPC exposed PHP functions.
How will you handle transport security?
Assuming you use HTTP as your transport-level protocol, the obvious answer to this is TLS. All the usual SSL/TLS security concerns apply here and many SE/SO questions already deal with these.
Since you control the client-side implementation, you should at least consider:
Choosing a strong cypher & disallowing poor cyphers
Dealing (or not dealing!) with re-negotiation in a sane way
Avoiding known-problematic implementations/features (e.g: OpenSSL 1.0.1-1.0.1f, heartbeat[CVE-2014-160]).
Will you need to handle positional/named/both style method arguments
Some JSON-RPC server-side implementations prefer that the params argument of the JSON-RPC envelope looks like params: [412, "something"] (positional), while others prefer that the params argument of the JSON-RPC envelope looks like params: { "type": "something", "num_events": 412 } (named). Still others can handle either style without issue. Your choice of client & server libraries should be informed by this issue of 'compatibility'.
Will you need to handle/send notification messages?
Notification messages are sent by the client or the server to the opposite party in order to communicate some updated/completed state over time. The sending party (ostensibly) shouldn't expect a response to a "notification" message.
Most JSON-RPC implementations use HTTP(S) for their transport protocol; as HTTP doesn't implement bi-directional asynchronous communications, you can't prooperly implement "notification" messages.
As your client side will be Android, you could use plain JSON text over TCP sockets as the transport protocol (rather than HTTP); as TCP does allow bi-directional asynchronous communications (once the socket is established), then you can properly implement "notification" messages.
Some libaries implement client-to-server notifications over HTTP transport by enqueing notification messages and then piggy-backing the notifications on request-style messages (possibily using "batch" requests -- see next question). Similarly some libraries implement server-to-client notifications over HTTP transport by piggy-backing the notifications on response-style messages (possibly using "batch" responses).
Still other libaries make use of HTTP by using WebSockets as their transport protocol. As this does allow bi-directional (essentially) asynchronous communications, then these libaries can properly implement "notification" messages.
If you don't need this you'll have significantly more choice in your selection of transport protocols (and therefore implementations).
Will you need to handle batch requests? Will you need to send batch
responses?
Sometimes it is desirable to send/handle groups of requests/responses/notifications in a single request/response (so called "batch" messages). The id argument of the JSON-RPC envelope is used to distinguish requests/responses in a batch.
If you don't need this you'll have significantly more choice in your selection of implementations ("batch messages" is the most commonly ommitted feature of JSON-RPC implementations).
How does the PHP implementation behave under a variety of exception / warning conditions?
PHP has many ways of propagating error conditions to the programmer and also has different types of error condition. Does the server-side implementation handle 'thrown' exceptions and PHP-level errors in a consistent manner? Is the error_reporting configuration appropriate (and does the library change it locally) ? Will the library interact poorly with debugging libraries (e.g: xdebug)?
Does the server-side implementation properly isolate JSON-RPC level errors from HTTP level errors? (i.e: does it prevent errors/exceptions inside a request lifecycle from becoming an HTTP-level error like 500: Internal Server Error).
Does the server-side implementation properly interact with your authentication & authorization mesures? (i.e: it might be desirable to promote related errors to 401: Unauthorized and 403: Forbidden HTTP statuses respectively).
Does the server-side implementation 'leak' sensitive information about your implementation or data-sources when delivering errors, either via HTTP or JSON-RPC?
These are pretty important questions to ask of a JSON-RPC webservice that will be used in a security minded setting. It's pretty hard to evaluate this for a given implementation by reading its documentation. You'll likely need to:
delve into its source code to look at the error handling strategies employed, and
perform extensive testing to avoid leaks and undesired propagation of error conditions.
How does the PHP implementation advise against or mitigate the PHP array set/list duality?
PHP is a crappy language. There. I said it :-)
One of the common issues JSON-RPC implementors deal with is how to properly map JSON arrays and JSON objects to language-native datastructures. While PHP uses the same data structure for both indexed and associative arrays, most languages do not. That includes JavaScript, whose language features/limitations informed the JSON (and therefore JSON-RPC) specifications.
As in PHP there is no way to distingish an empty indexed array from an empty associative array, and as various naughty things can be done to muddy existing arrays (e.g: set associative key on existing indexed array) various solutions have been proposed to deal with this issue.
One common mitigation is that the JSON-RPC implementation might force the author to cast all intended-associative arrays to (object) before returning them, and then reject at run-time any (implicity or intended) indexed arrays that have non-confirming keys or non-sequential indexes. Some other server-side libraries force authors to annotate their methods such that the intended array semantics are known at 'compile' time; some try to determine typing through automatic introspection(bad bad bad). Still other sever-side libraries leave this to chance.
The mitigations present/missing in the server-side PHP JSON-RPC implementation will probably be quite indicative as to its quality :-)
Will you need to implement SMD?
SMD is a not-very-standardized extension to JSON-RPC "-like" protocols to allow publishing of WSDL-like information about the webservice endpoint and the functions (no classes, although conventions for namespacing can be found out there) it exposes.
Sometimes 'typing' and 'authorization' concerns are layered with the class/function "annotations" used to implement SMD.
This 'standard' is not well supported in either client or server implementations :-)
Will your web-service also need to perform other HTTP-level routing?
(e.g: to static resources)
Some server-side implementations make all sorts of assumptions about how soon during the HTTP request cycle they'll be asked to get involved. This can sometimes complicate matters if the JSON-RPC implementation either implements the HTTP server itself, or constrains the content of all received HTTP messages.
You can often work around these issues by proxying known-JSON-RPC requests to a separate web server, or by routing non-JSON-RPC requests to a separate web-server.
If you need to serve JSON-RPC and non-JSON-RPC resources from the same webserver, ask yourself if the server-side JSON-RPC implemenation makes this impossible, or whether it makes you jump through hoops to work around it.
I have made a Java EE 6 application where a user can browse a set of questions, add new questions and so on. The user can optionally log in so that he/she gets "credit" for adding the question or reporting it as bad.
Now I want to make a iPhone application where the user can do pretty much the same. So the answer is web service I assume. I have not worked with web service before but I see there are at least to alternatives: SOAP and REST.
Which one should I choose? I want the user to be able to log in from the application as well a as browse the questions in the database...pretty much many of the actions you can do on the web site.
I don't know much about the security and overhead they introduce.
Also I want the user to be able to retrieve the list of questions thorugh the web server and have the option to save it, so he/she won't need to have internet unless he/she wants to update it. Can I achieve this with both web services?
REST has less overhead than SOAP (WSDL contract, XML messages, supporting frameworks) so when the client is a mobile device REST seems more suitable. You could use JAX-RS (Jersey) to easily create REST services on the server side. The client request consists of the url structure and/or parameters like http://yourserver/questions/view/342 (to view question 342) or http://yourserver/questions/search?q=REST+vs+SOAP (to search for questions about REST vs SOAP). The response can be anything you want, but XML or JSON is pretty common.
Choosing REST means you will be leaning heavily on the HTTP protocol. For security a common approach is to use HTTP Basic authentication in combination with https. Basic authentication means you add an 'Authentication:' header to your HTTP request containing a Base64 encoded username:password pair. Note that Base64 does not encrypt anything, it just obfuscates. To avoid eavesdropping you need to use at least https meaning requests are encrypted using the server's public key. These requests can only be decrypted with the server's private key. To use https you need to set up the server with a certificate. If you want to avoid warnings about the certificate being 'untrusted' it needs to be issued by a recognized SSL certificate provider. For testing you can just generate it yourself.
Finally you asked about saving a list of questions for offline usage. This is a concern of the app, not of the service. To do this you need to store the retrieved data on the device and access that data if the device goes offline. I am not an iPhone developer, but I can imagine you could use a flat file or some lightweight database to store the data. When the device is offline, the app component that retrieves data should switch from network access to local storage access. Also some app functionalities like adding a question might need to be disabled. If you don't disable these, you would need to temporarily store any data entered by the user and send it to the server when the device comes online again. This could be a bit tricky to get right so my advice would be to leave this for later.
You can take a look at this previous SO post for some guidance. I would recommend using REST, it seems to be less messy than SOAP and Java has support available for it as shown here.
Through the use of annotations, you can simply created a facade to which users will connect. In turn, this facade will call the relevant logic which I am presuming you already have.
Well on a simple search REST vs SOAP, you will eventually get to this
There are plenty of other articles and even in-depth research papers, so it's only a matter of - do you really want to get serious with your research VS not really
Good luck!
Short answer: Yes, you can achieve that with web services.
Web services are only a facade to your system - they can expose (or not) any behavior you want to. If you have security concerns, you'll have to approach them anyway in both methods.
Personally, I'd use a RESTful approach as its usually simpler to implement and use. From Wikipedia:
A RESTful web service (also called a RESTful web API) is a simple web
service implemented using HTTP and the principles of REST. It is a
collection of resources, with four defined aspects:
the base URI for the web service, such as http://example.com/resources/
the Internet media type of the data supported by the web service. This is often JSON, >XML or YAML but can be any other valid Internet media type.
the set of operations supported by the web service using HTTP methods (e.g., GET, >PUT, POST, or DELETE).
The API must be hypertext driven.[11]
So you'd have a URL, say http://mywebsite.com/users and perform HTTP actions (GET, PUT, etc) on them. A GET request on /users/17 could return user 17, for instance, while a POST request on it would update said user.
As for login, when your users "log in" you would call a GET method that sends username:password (probably encrypted) and returns a login token. Every time the user executes an action, you would send said token with the request as an additional parameter.