I am working on my graduate thesis about RESTful web services in Spark micro framework and I want to talk a little about HTTP 1.1 protocol specifically HTTP methods. Problem is I am a bit confused with the reference documentation cause till now in my graduate thesis I've used HTTP 1.1 RFC2616 as my reference documentation but I see that there is a lot of new updated versions like RFC7230 and I am confused which one is the current one that is used. I am currently using jetty-9.4.4.v20170414 as my server and I can see that the server uses HTTP 1.1 but I am not sure if I am describing the right version of HTTP used in my jetty server?
2616 has been obsolete since June 2014, when they released 723x. Each of 7230-7235 have a section at the end that describes what changes there are since 2616. I can't speak to what's being used in Jetty, but there are not many substantiative changes between the documents, so if that version of Jetty is relatively recent, I'd expect it conforms to the new specs. Have you tried asking the Jetty authors?
Related
It is often said that you should use PUT, DELETE, and other methods of HTTP 1.1 to provide a RESTful API. The purpose is to make URI to reference a resource (representation) and the method designate the action to be done. I see that HTTP 1.1 was released in 1997 and Fielding's PhD paper introducing REST took place in 2000. So, why those methods, besides GET and POST, were really added into the HTML 1.1 spec in the first place?
It would be great to have a reference on an article of something like that explaining why HTTP 1.1 method set was expanded since HTTP 1.0 without references to REST that appeared 3 years later.
HTTP/1.0 had PUT and DELETE and predated the dissertation by several years.
https://www.ietf.org/rfc/rfc1945.txt
Document is from 1996.
Aside from that, the REST dissertation was meant to describe the architecture of the web itself, not JSON apis (you didn't explicitly mention this but it's a common misconception). HTTP and HTML are an implementation of the REST architecture, even though REST was described after the first few versions HTML and HTTP.
So if you're curious if HTTP/1.1 sometimes describes things in a way that matches the REST dissertation, I think that kinda goes without saying. They had the same author, they were written around the same time and the one documentation describes the REST architecture, and the other is (part of) an implementation of the REST architecture.
I have a java codebase that seems to be using "com.google.api.services.cloudkms.v1.CloudKMS" to call KMS. The online docs says to use "com.google.cloud.kms.v1.KeyManagementServiceClient"
When i looked up both packages seem to be updated, however the reference docs recommend using the latter.
https://developers.google.com/resources/api-libraries/documentation/cloudkms/v1/java/latest/com/google/api/services/cloudkms/v1/CloudKMS.html
https://cloud.google.com/kms/docs/reference/libraries
Could someone tell me what is the difference between these 2 clients packages and if i should move to the one the reference links to?
In general, you should prefer the library referenced on the Reference Libraries page, currently com.google.cloud.kms. The examples and tutorials on the website will use this client library.
Probably more history than you need to know, but we have two client libraries because they run over different protocols. The new libraries (the one's listed on the reference page) use gRPC to communicate. This means less bandwidth and less time spent serializing/de-serializing JSON. On the flip side, gRPC requires HTTP/2, and some organizations can't/won't support HTTP/2 yet. As a result, we still publish and maintain legacy libraries that are REST over HTTP/1. It is strongly recommended you use the gRPC ones unless you can't use HTTP/2.
You can read more about the background and technical details in Kickstart your cryptography with new Cloud KMS client libraries and samples.
The Vert.x documentation says that Scala (and Clojure) will be supported 'soon'.
What's actually missing for using it with Scala as is??
So, as of 2013/11/04:
Scala support has everything up to Vert.x 2.0.2-final plus DNS support. So you need 2.1M1 of Vert.x core and the 0.2.0 release of Scala.
We need to add UDP support, EventBus timeouts (mostly done, but there seems to be a bug in the vert.x core project: https://bugs.eclipse.org/bugs/show_bug.cgi?id=420850 ), provide asynchronous registerHandler methods (as these changed to async style) and provide a solution for the unregisterHandler problem we were facing (probably use the asynchronous registerHandler to provide a RegisteredHandler object that has an unregisterHandler() method).
and a followup
Update: EventBus timeouts are done, waiting for review in pull request https://github.com/vert-x/mod-lang-scala/pull/77
I forgot to mention that HTTP Compression was also missing. Just added another PR to review here: https://github.com/vert-x/mod-lang-scala/pull/78
Also added docs for both of them.
To recap what's still missing:
UDP support + test + docs
asynchronous registerHandler methods + test + docs
unregisterHandler issue + tests + docs (I guess this should be done with the asynchronous registerHandler providing a AsyncResult[RegisteredHandler] => Unit callback)
Also announced today:
I'm really proud to announce the release of Vert.x Scala 0.2.0 which includes full Vert.x 2.0 API support as well as new DNS API support coming up in Vert.x 2.1. This means that mod-lang-scala 0.2.0 now requires Vert.x 2.1.
The amazing API work has been driven by the tireless Joern Bernhardt and his colleague Sascha Schmidt. Between them two they've added all the missing APIs and reworked the testsuite to add Scala specific testtools. This was a big tasks and both Joern and Sascha deserve full credit for pulling this off. Kudos to both for this fantastic work!! :). On top of this, we've also added the capability to deploy Scala scripts into Vert.x, bringing the Vert.x Scala examples in line with other languages.
For next release, 0.3.0, we'll be focusing on polishing some these APIs, adding new APIs that Vert.x 2.1 brings, documentation and more examples :)
While we complete the documentation, the best place to get started with the Scala language module is to look at the README file in the Vert.x mod-lang-scala repository.
I am trying to send an ActiveMQ StreamMessage from a C++ (CMS) client to a Java (JMS) client. However, the Java client is unable to correctly read the values from the incoming message - most fields are extracted as null, and the fields that do have values associated with them just seem to contain garbage.
I can send BytesMessages and TextMessages from our C++ client to our Java client just fine, so the BytesMessage is our fallback for now.
However, the misbehaving StreamMessage is making us suspect something is wrong/incompatible between our two clients.
We are using ActiveMQ 5.4.2 on the Java side, and activemq-cpp 3.0.1 on the C++ side.
Are there any known incompatibilities between the JMS and CMS implementations, or are there any other obvious pitfalls I should look for?
I think there were some issues that I fixed somewhere between 3.0.1 and the latest 3.2.4 that fixed some issues with stream message. I'd really recommend that you update to v3.2.4 of CMS as there's been a large number of bugs fixed, along with some great new features.
The CMS issue tracker is here if you want to review to issues fixed since the version you are using:
Edit: Found the issue that fixed it, its here.
-Tim
www.fusesource.com
The numerous technologies for writing SOAP web services allow me to create services which adhere to either SOAP 1.1 or 1.2. It's not clear to me what benefits 1.2 provides over and above 1.1. This leads me to the conclusion that I should always use 1.1 to accommodate the largest number of compatible clients.
Why would I choose to create a SOAP 1.2 rather than a SOAP 1.1 web service?
From practical standpoint this is the case when you don't need SOAP1.2 if you're happy with 1.1, at least for now.
1.2 is quite different standard, its messages are infoset-based and (most notably) it is protocol-agnostic (you can use your own binary protocol for message delivery) and it is not backwards-compatible with 1.1.
You could read more here. Note the "Related information" section.