Develop Reference

validate REST endpoint design

REST endpoint design says: Not use verb
In an workflow-like create Employee which has multi-tab style like "Basic Details", "Educational Details", "Work Experience", etc... One first tab data is filled continue button is pushed resulting in an backend API call which just validates the detail in that tab and returns the list of validation errors if any or moves to next tab for the user to fill data. So basically this calls for validate API for each of the tabs with no intention of saving data. Now one thing that comes naturally is below:
POST /employee/basic/validate
(removing api versioning details from endpoint for simplicity)
But using validate in API means verb. How to design then?
There's a separate flow where one can just save "basic details" of employee - so its like any normal API validate and save - so POST /employee/basic/ is good for that case.

REST endpoint design says: Not use verb
That's not a REST constraint - REST doesn't care what spellings you use for your resource identifiers.
All of these URL work, exactly the way that your browser expects them to:
https://www.merriam-webster.com/dictionary/post
https://www.merriam-webster.com/dictionary/get
https://www.merriam-webster.com/dictionary/put
https://www.merriam-webster.com/dictionary/patch
https://www.merriam-webster.com/dictionary/delete
Resources are generalizations of documents; the nature of the HTTP uniform interface is that we have a large set of documents, and a small number of messages that we can send to them.
So if you want a good resource identifier, the important thing to consider is the nature of the "document" that you are targeting with the request.
For instance, the document you are using to validate user inputs might be the validation policy; or you might instead prefer to think of that document as an index into a collection of validation reports (where we have one report available for each input).

Seems that what you try to do in the end is to run your operation in dry-run mode.
My suggestion would be to add a dry-run option as request parameter for instance.
/employee/basic?dry-run=true

REST says that you should use standards like HTTP to achieve a uniform interface. There are no URL standards as far as I know, even OData says that its URL naming conventions are optional.
Another thing that the browser is a bad REST client. REST was designed for webservices and machine to machine communication, not for the communication of browsers with webapplications, which is sort of human to machine communication. It is for solving problems like automatically order from the wholesaler to fill my webshop with new items, etc. If you check in this scenario both the REST service and REST client are on servers and have nothing to do with the browser. If you want to use REST from the browser, then it might be better to use a javascript based REST client. So using the browser with HTML forms as a REST client is something extreme.
If you have a multitab form, then it is usually collected into a session in regular webapplications until it is finalized. So one solution is having a regular webapplication, which is what you actually have, since I am pretty sure you have no idea about the mandatory REST constraints described by Fielding. In this case you just do it as you want to and forget about REST.
As of naming something that does validation I would do something like POST /employee/basic/validation and return the validation result along with 200 ok. Though most validation rules like "is it a date", "is it a number", etc. can be done on the clients currently they can be done even in HTML. You can collect the input in a session on server or client side and save it in the database after finilazing the employee description.
As of the REST way I would have a hyperlink that describes all the parameters along with their validations and let the REST client make tabs and do the REST. At the end the only time it would communicate with the REST service is when the actual POST is sent. The REST client can be in browser and collect the input into a variable or cookies or localstorage with javascript, or the REST client can be on server and collect the input into a server side session for example. As of the REST service the communication with it must be stateless, so it cannot maintain server side session, only JWT for example where all the session data is sent with every request.
If you want to save each tab in the webservice before finalizing, then your problem is something like the on that is solved with the builder design pattern in programming. In that case I would do something like POST /employeeRegistrationBuilder at the first step, and which would return a new resource something like /employeeRegistrationBuilder/1. After that I can do something like PUT/POST /employeeRegistrationBuilder/1/basics, PUT/POST /employeeRegistrationBuilder/1/education, PUT/POST /employeeRegistrationBuilder/1/workExperience, etc. and finalize it with PUT/POST /employeeRegistrationBuilder/1/finished. Though you can spare the first and the last steps and create the resource with the basics and finish it automagically after the workExperience is sent. Cancelling it would be DELETE /employeeRegistrationBuilder/1, modifying previous tabs would be PUT/PATCH /employeeRegistrationBuilder/1/basics. Removing previous tabs would be DELETE /employeeRegistrationBuilder/1/basics.
A more general approach is having a sort of transaction builder and do something like this:
POST /transactions/ {type:"multistep", method: "POST", id: "/employee/"}
-> {id: "/transactions/1", links: [...]}
PATCH /transactions/1 {append: "basics", ...}
PATCH /transactions/1 {append: "education", ...}
PATCH /transactions/1 {remove: "basics", ...}
PATCH /transactions/1 {append: "workExperience", ...}
PATCH /transactions/1 {append: "basics", ...}
...
POST /employee/ {type: "transaction", id: "/transactions/1"}
-> /employee/123
With this approach you can create a new employee both in multiple steps or in a single step depending on whether you send actual input data or a transaction reference with POST /employee.
From data protection (GDPR) perspective the transaction can be the preparation of a contract, committing the transaction can be signing the contract.

REST API Single Request - Multiple responses

I am writing a REST API in JAX-RS 2.0, JDK 8 for the below requirement
POST API /server/fileUpload/ (Multipart Form data) where I need to send a Big .AI (Adobe Illustrator) File in this.
The Server, takes the file and return Status 202 (Accepted), Acknowledging that file transfer happened Successfully. (From endpoint to Server)
Now at the Server, I am using Java + Imagemagik to convert .AI File (20-25 MB File) to small JPG Thumbnail, place on a Apache HTTP Server and share the location (like http://happyplace/thumbnail0987.jpg)
Now the Second Response should come from Server with Status 200 OK and Thumbnail URL
is it feasible with one REST API? (Async/similar)
or should I split it to 2 API calls, Please suggest

No. In http, one request gets one response. The client must send a second request to get a second response.

You can use WebSockets for that.

If you are calling from script the call will be async you can handle the Thumbnail URL when you get a response. When you are calling from java program i suggest to run it on a different thread, If the execution is not sequential i.e ( Remaining lines can be executed without getting URL). If url is needed for the remaining section of code you can make one call and wait for the response then execute remaining code.

You need to make different APIs for both scenarios. One for showing file upload status and another for all file conversion and manipulation.
On the client side second request must be callback of first request.

The best way to handle these kind of scenario is to use Java Reactive (Project Reactor, WebFlux).

You can return two response using custom middlewares in asp.net (however not recommended).
Return response from one middleware and subsequently you can invoke next middleware and return second response from second middleware

Java JAIN SIP Presence

I am currently writing an application in java using the the JAIN SIP library, I've been trying for the past couple of days to implement presence using SUBSCRIBE and NOTIFY messages. I currently have NOTIFY messages which has a content type of "message/sipfrag;version=2.0", and need this to be XML and PIDF.
I'm aware I need to use an event header with "presence", and also a content type header.
Are there any places I can go to where there is information on this or are there any other specific headers or classes and/or methods needed to make this work? I already have a client which I can make calls on, but need to implement presence now.

FYI, rfc3863 only defines the basic structure/semantics of a presence document. PIDF establishes a rudimentary presence document to be a status - with optional contact info, and other info (defined per the PIDF schema). PIDF does not really prescribe presence protocol. For those you need to review [RFC3265][1] and the details of the presence event package [RFC3856][2]. If we stick to a non-IMS network, the usual call-flow involves:
SIP registration to the SIP/REGISTRAR user-agent-server (UAS) accessible to the client. This also establishes the presence-entities (presentity) AoR (Address of Record) - who you are and how you can be reached - i.e. assuming you want to be contacted.
SIP:PUBLISH - with 3 very key parts. Firstly, an 'Event' header indicating support for the presence package, the content-type appropriately set to PIDF MIME-type and the correct body.
PUBLISH sip:bob#example.org SIP/2.0
...
Event: presence
Content-type: application/pidf+xml
Content-length: xyz
open
Once you have successfully published, you can then try a SUBSCRIBE method - to try and obtain status of another presence entity (e.g. user jane#example.org). For a SIP SUBSCRIBE the minimal is defining an appropriate presentities SIP/URI and specifying the correct 'event-package'. Look closely at the indicated RFCs - 3265 / 3856 will help guide you on basic behavior.
Best of luck.
[1]: https://www.rfc-editor.org/rfc/rfc3265#section-4
[2]: https://www.rfc-editor.org/rfc/rfc3856#section-5

There is more than one way to do presence in SIP. If you are sure PIDF is used then you should just use the RFC as reference https://www.ietf.org/rfc/rfc3863.txt. JSIP will work just fine as far as the SIP headers go, it will construct and parse the SIP messages correctly. The actual SIP message content parsing/construction is responsibility of the app. Jitsi is an open source client that has presence if you want to peek at some example code, but it may be totally different from your case.

Play-Framework & Ajax how to?

I'm looking to do the following with AJAX...
I have a request to my server that takes a considerable amount of time to complete. The request is made in the controller and upon completion a HTML page is loaded informing the user of its completion.
However, what I'd like to do is have the request sent asynchronously, load the completion page and then load the requests result once it become available. I assume I would use AJAX to do this but I'm not exactly sure how. Can anyone point me to a good guide for doing something like this?
In case my explanation above is too confusing here is what I want to do...
1) Send request to server from Controller asyncronously.
2) load HTML page.
3) When request has completed fill field in already loaded HTML page with the response from the request.

I wrote a tutorial recently that walks through how to do this with Play 1.2, JSON, and jQuery:
Tutorial: Play Framework, JPA, JSON, jQuery, & Heroku

There are 2 parts you need to take into account here:
The client side
The server side
For the client side; an Ajax request (for example, using jQuery.ajax) is per definition asynchronous. This means that you should be able to do the following - again using jQuery, which makes things easier - in your HTML page:
// The ready handler, which fires when the page has been loaded
$(function() {
jQuery.ajax(
// Do your thing here
);
});
For the server side; in case your operation is going to be running for a relatively long time on the server (for instance several web service calls or long running IO operations) you'll want to use Play's asynchronous capabilities to let the Play! server execute things as effeciently as possible. It does this by offloading the long running operation(s) to their own threads.
The only thing left to do is set-up a route to your controller, implement the handler method and render something that your client-side JavaScript code is capable of parsing (JSON is probably the easiest, using Play's renderJson()).
I haven't used this set-up myself - maybe someone can confirm this would be the way to do it?

Prevent user from opening JSF page in more than one tab/window in a browser

Is it possible to prevent user from opening JSF page in more than one browser tab or window?

I agree with the accepted solution, but if you still have to do it, these steps worked for me (pseudo code/pseudo python):
On the JS side:
if tabId not set:
. generate random number
. set property in sessionStorage
otherwise:
. get it from sessionStorage
make an ajax callback and send tabId
onError:
. alert();
. close current tab (if possible);
. logout
Backend:(JSF):
Create custom filter:
if request contains the tabId info:
if it matches session's tabId: (being tabId not null)
sent response status code to an error such as forbidden
Optionally invalidate session
otherwise apply session filtering (do nothing)

#BalusC The problem concerns old JSF application that is entirely stateful. Why try to figure out some way to inform users that openning the app in two separate tabs is potentially dangerous. In no way can we change session managed beans to request managed beans.
Make all those beans request scoped, install Tomahawk, add <t:saveState value="#{bean}" /> for every bean to every view of which you'd like to retain exactly the same bean state in the subsequent request. This works independently across tabs/windows.
Without Tomahawk, the alternative would be adding <h:inputHidden /> for every bean property which you'd like to retain in the subsequent request. I can however imagine that this may produce nasty boilerplate code when there are much or when they aren't of the standard EL types (for which you have thus to create a Converter). But that's what you get paid for.

One scenario I have in mind:
Put a javascript component in the page that will constantly sending heartbeat to the server via AJAX. As long as there are heartbeat sent from browser, this page will be flagged as 'currently_viewing'. And as long as a page have that flag on, other requests to that page should be rejected.
The detail may be a lot messier than this simple story (e.g. you might need to have some sort of 'page id' to be sent with the heartbeat), but you get the idea (... i hope :).
Everything is possible as long as you are willing to pay the price.