We Keep Coding

I need a SOAP endpoint start page like Axis provides

I am migrating a Spring2 SOAP service to Spring 5. in the old code, if I called https://server:port/myservice/services/myserviceendpoint from a browser, it would display a page stating "And now... Some Services"
The spring-ws doesn't do that. unfortunately one of the client apps uses that page to determine if the service is up.
How do I mimic that behavior?

It's a matter of handling HTTP requests the same way Axis does. Normally, you have to deal with three combinations:
GET /myserviceendpoint
GET /myserviceendpoint?wsdl
POST /myserviceendpoint
Your SOAP service works with POST, so you have that covered by the service itself. All you have to do is create an URL mapping for GET and return the response expected by your client. If it's a plain GET, you return HTML with the "And now... Some Services". If the GET has the ?wsdl parameter, you should return a WSDL for the service. Obviously, you will need to replicate whatever else content the client is expecting.
With that being said, is there a way for the client to stop doing that? They are using something dependent on the implementation. That Axis page is there just to test everything is set up properly. Normally, it shouldn't have been exposed to clients, let alone the clients using it to make sure the service is up.
If they want to make sure the service is up, then, while you are migrating this service to Spring 5, what you can do is add another operation in the service, something called <ping> that responds with a <pong> or something. Basically, to offer an operation on the service that can be called with no side effects to see if the service is up. Since this is a new operation, it's a non breaking change (for both the service and the WSDL) so it's safe to add. Then clients can have something to use instead of relying on other mechanisms offered by your code implementation .

Using the REST API of Twilio

Not being familiar with REST and after reading some doc about it I am a little bit confused about the way it works.
I actually want to use Twilio SMS Gateway that provides a REST API to interact with and send text messages from an existing web-application.
From what I understand, REST is a way to structure a web service and in the end, instead of using SOAP for example, we just access 'resources' with URLs, relying on HTTP to GET, PUT or DELETE data.
The SMS Gateway I am talking about is providing a Java API that I could integrate to my web-app. The classes in this API uses httpcore, httpclient and commons-codec jars. Is this because REST rely on HTTP?
So basically, their API is relying on the Apache and HTTP libs to construct HTTP requests in Java and setting the basics, so I just have to provide with the data I want to submit and/or specific information?

REST API's are HTTP API's. The word REST is supposed to indicate something about how your API works. Basically that you use POST requests to update data and GET requests to retrieve it, and you have different HTTP endpoints for all of the different resources in your API, like Calls or Recordings.
The Twilio helper libraries (including the Java library) are basically wrappers around HTTP calls to the Twilio API. The idea was to make it easier for you to make API calls to Twilio by abstracting away the HTTP authentication and request stuff behind some more language-specific code. We also parse the HTTP response into an object for you.

How do I send a request using the PATCH method for a Salesforce update?

I'm using the Play framework to build a web app which integrates with Salesforce via their REST API. In order to send an upsert command to their interface, it seems as if I must use the PATCH method instead of a POST method request. Is it possible to use Play's WSRequest object and change the method type to PATCH instead of POST? If not, how can I use a request object and send a PATCH request instead?
For learning purposes, what is the PATCH method and why does Salesforce enforce use of it instead of a POST method?

I'm not sure about what is available in Play, but from the REST API documentation, here is a workaround if your library doesn't support PATCH:
If you use an HTTP library that doesn't allow overriding or setting an
arbitrary HTTP method name, you can send a POST request and provide an
override to the HTTP method via the query string parameter
_HttpMethod.
For example, to update an Account, this will work with an actual POST request:
.../services/data/v23.0/sobjects/Account/0016000000eEhmxAAC?_HttpMethod=PATCH
As for the reasoning behind using PATCH, it is because PATCH is for partial updates to a resource. That is, you only have to send the fields you are updating. If you were required to send all the fields for a record in updates, PUT would probably be a better choice. POST is generally only for new inserts. Here is an explanation with examples:
http://jasonsirota.com/rest-partial-updates-use-post-put-or-patch

Play doesn't include a PATCH method in his WS library.
You could manually extend some classes from the framework in your app to add this method (mainly these two), but I believe that the alternative provided by #ryanbrainard is a beter approach: use the _HttpMethod parameter in a POST to flag is as PATCH.

Post data from Server side in Spring MVC

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.

Implementing an HTTP proxy to overcome cross-site AJAX requests restrictions (?)

I have a Spring-MVC webapp (3.0.5-RELEASE) which needs to access JSON webservices from another webapp on a different sub-domain (from the client/browser via AJAX).
I've solved this in the past by either:
writing a simple controller that proxies the requests, using Apache Commons HttpClient to handle the requests. Thus overcoming the cross-site/cross-origin request security limitations of most browsers
implementing a JSONP service on the server side (when calling our own JSON services) - not always possible
In the case where JSONP is not possible, is there a better way of doing (1.)?
and/or
Is there a library that will handle this for me? So I don't have to write all the HttpClient code myself - its not a lot of code, but I wonder if I'm (badly) re-inventing the wheel.

I have often had to consume third party web services (API), and as you mentioned, JSONP is not always an option. This is how I go about designing:
If the API is user centric, it has to provide a jsonp interface and that's what I will use. User centric means that you cannot perceive any reason to call the API, do some computations with the response, may be call one of your ajax services and then combine the response and show the user.
If my use case includes calling the API, and then acting on the response, like calling additional services from my application, combining the data and then showing it to the user, I would prefer not doing this in the browser. I would instead use RestTemplate and make backend api calls to the service. In which case there are no cross domain restrictions.
The only case where using a Server Proxy to bypass jsonp is when you are creating a Product that allows people to build custom plugins, plugins which are hosted on your page, but need to make Ajax calls to the app developers servers. This is a very involved case! (As as example look at how Apigee creates Public Facing REST API around your existing urls, or how Zendesk allows you to develop apps)
Hope this helps.