私は、新しいリソースが作成されていることを確認し、表Aからのデータは表Bに行くのサービスはRESTサーバにPOSTリクエストを送信し、各行がコピーされたため、ロケーションヘッダを応答として作成されるJavaサービスに取り組んでいるとGETリクエストが新たに作成されたリソースに対して発行されたときにJSONとしてPOJOを返します。これは、ハンドルPOSTが要求したリソースの方法です。
@POST
@Produces({MediaType.APPLICATION_JSON})
public Response migrateToMinio(@Context UriInfo uriInfo) throws Exception {
tiedostoService = new TiedostoService();
attachmentService = new AttachmentService();
List<Tiedosto> tiedostoList = tiedostoService.getAllFiles();
List<String> responseList = new ArrayList<>();
Response r;
Integer newRow;
String responseData = null;
int i=1;
for (Tiedosto tiedosto : tiedostoList) {
Attachment attachment = new Attachment();
attachment.setCustomerId(tiedosto.getCustomerId());
attachment.setSize(tiedosto.getFileSize());
newRow = attachmentService.createNew(attachment);
UriBuilder builder = uriInfo.getAbsolutePathBuilder();
if (newRow == 1) {
builder.path(Integer.toString(i));
r = Response.created(builder.build()).build();
responseData = r.getLocation().toString();
i++;
}
responseList.add(responseData);
}
String jsonString = new Gson().toJson(responseList);
return Response.status(Response.Status.OK).entity(jsonString).build();
}
tiedostoServiceそしてattachmentService二つのテーブルのためのサービスクラスです。tiedostoListすべての行があるtiedosto表を添付し、表に新しい行が内のすべての項目のために作成されるように、forループ内の反復されていますtiedostoList。私はPOSTリクエストを送信すると/rest/attachments、それはプロセスには数秒かかり、このように作成されたリソースのリストをステータス200を返します。
さて、私の質問は、新しく作成されたリソースの場所が最終ステータス200を待つことなく、それの作成後に（多分201が作成した）すぐに返されるようにそれを実装する方法はありますか？
Such a solution would presume that you the service saving the attachment (AttachmentService) would be able to compute the location prior to saving it. For example, the service should be able to know that if the last attachment was stored with an ID of 10, the next attachment would be stored with an ID of 11 (or however the subsequent ID would be calculated) and therefore would have a location of http://localhost:8080/rest/attachments/11.
Presuming that logic is possible in your service, you could create a receipt object that contains the location of the created resource and a future that represents the saved resource. This receipt object can be returned by the service instead of the attachment itself. The implementation of such a receipt object could resemble the following:
public class CreationReceipt<T> {
private final String location;
private final Future<T> attachment;
public CreationReceipt(String location, Future<T> attachment) {
this.location = location;
this.attachment = attachment;
}
public String getLocation() {
return location;
}
public Future<T> getAttachment() {
return attachment;
}
}
In AttachmentService, there would exist a method that stores a new Attachment and returns a CreationReceipt<Attachment>:
public class AttachmentService {
public CreationReceipt<Attachment> createNew(Attachment attachment) {
String location = computeLocationFor(attachment);
Future<Attachment> savedAttachment = saveAsynchronously(attachment);
return new CreationReceipt<>(location, savedAttachment);
}
private Future<Attachment> saveAsynchronously(Attachment attachment) { ... }
private String computeLocationFor(Attachment attachment) { ... }
}
The logic for pre-computing the location of an Attachment will depend on the specifics of your application (and I will leave it stubbed for you to add the logic), but the logic for saving an Attachment asynchronously can follow a common pattern. Using an ExecutorService, synchronous logic for saving an Attachment (which your application already uses) can be made asynchronous. To do this, the synchronous logic is submitted to an ExecutorService (using the submit method) and a Future is returned by the ExecutorService which wraps the saved Attachment and will complete when the Attachment is successfully saved.
An example (albeit incomplete) implementation would resemble:
public class AttachmentService {
private final ExecutorService executor = Executors.newSingleThreadExecutor();
public CreationReceipt<Attachment> createNew(Attachment attachment) {
String location = computeLocationFor(attachment);
Future<Attachment> savedAttachment = saveAsynchronously(attachment);
return new CreationReceipt<>(location, savedAttachment);
}
private Future<Attachment> saveAsynchronously(Attachment attachment) {
return executor.submit(() -> save(attachment));
}
private Attachment save(Attachment attachment) { ... }
private String computeLocationFor(Attachment attachment) { ... }
}
この実装は唯一可能にすることに注意してくださいAttachment（使用の性質により、時間に保存されるがExecutors.newSingleThreadExecutor()）が、その論理が定義することによって変更することができるexecutor異なる使用するExecutorService実装。この実装を完了するためには、単にのための実装追加save同期新しい節約方法Attachmentオブジェクトを（この同期ロジックは、既存に記載されていなければならないcreateNewからメソッドAttachmentService）。
この時点から、保存するためのロジックは、Attachment次のようになります。
List<String> savedLocations = new ArrayList<>();
for (Tiedosto tiedosto : tiedostoList) {
Attachment attachment = new Attachment();
attachment.setCustomerId(tiedosto.getCustomerId());
attachment.setSize(tiedosto.getFileSize());
CreationReceipt<Attachment> receipt = attachmentService.createNew(attachmentToSave);
savedLocations.add(receipt.getLocation());
}
// Do something with savedLocations
これは不完全な実装であるが、それが使用される基本的な構造を示すべき。ループが完了したら、あなたは含めることができsaveLocations、応答の本体として、およびへの応答ステータスコードを設定します201 Created。