Enhavtabelo[Kaŝi][Montri]
- 1. Kion vi komprenas per REST?
- 2. Kion vi volas diri per REST API?
- 3. Kio ĝuste estas URI?
- 4. Kio estas la karakterizaĵoj de RESTful Retejaj Servoj?
- 5. Kio estas la gvidprincipoj de REST?
- 6. Menciu la HTTP-metodojn, kiujn REST subtenas.
- 7. Priskribu la limigojn metitajn de konsekvenca interfaco.
- 8. Kio ĝuste estas REST-Rimedo?
- 9. Kion signifas por vi JAX-RS?
- 10. Kio distingas AJAX kaj REST unu de la alia?
- 11. Ĉu vi povas listigi iujn malavantaĝojn de RESTful-retaj servoj?
- 12. Kio distingas PUT kaj POST-teknikojn unu de la alia?
- 13. Kiel vi testas RESTful-retajn servojn?
- 14. Priskribu REST API en la reala mondo.
- 15. Kiel Funkcias Mikroserva Arkitekturo?
- 16. Kio ĝuste estas kaŝmemoro?
- 17. Priskribu utilan ŝarĝon.
- 18. Diferenci SAPO Vs REST?
- 19. Ĉu la transporttavola sekureca protokolo (TLS) povas esti uzata kun REST?
- 20. Idempotentaj metodoj: kio ili estas? Kiel ĝi validas por la mondo de RESTful-retservoj?
- 21. Kio estas la funkcieco de HTTP Baza Aŭtentigo?
- 22. Ĉu vi pensas, ke GraphQL estas la plej bona elekto por krei mikroservan arkitekturon?
- 23. Kio estas la ĉefaj distingoj inter la sekuraj kaj idempotentaj HTTP-metodoj?
- 24. Kion implicas la JAX-RS API per RESTful Root Resource Classes?
- 25. Kio precize estas Poŝtisto, kaj kial ĝi estas uzata?
- 26. Kiel estas REST-APIoj sekuraj?
- konkludo
La evoluo de REST igis API-ojn nekredeble alireblaj dum ankaŭ malkaŝis ilian plenan forton kaj potencialon. REST-APIoj estas facile kreeblaj kaj konserveblaj pro sia rimeda arkitekturo.
Krome, laŭlonge de la tempo, RESTful-APIoj estis la antaŭuloj de aliaj signifaj evoluoj kiel nuba komputado kaj mikroservo-bazita dezajno.
Sekve, ne surprizas, ke REST-API-programistoj estas postulataj hodiaŭ pro kiel ili provizas entreprenojn, kiuj uzas RESTful-servojn, konkurencivan avantaĝon. REST-APIoj estas populara dezajna tendenco.
Multaj IT-firmaoj volas REST-API-scion de programistoj kaj demandu pri ĝi en teknikaj intervjuoj.
Jen kelkaj el la plej tipaj intervjuaj demandoj de REST API, kiuj helpos vin esti preta por intervjuoj ĉe diversaj firmaoj, se vi volas labori en la disvolva kampo de REST API.
1. Kion vi komprenas per REST?
REST estas arkitektura paradigmo por dizajni ret-bazitajn aplikojn kiuj estas bazitaj sur la Hiperteksta Transiga Protokolo (HTTP).
REST difinas certajn normojn, kiujn retservoj devas plenumi por esti konsiderataj RESTplenaj. Ĉi tiuj rekomendoj garantias, ke petoj kaj rimedoj estas elsenditaj rapide kaj efike inter kliento kaj servilo uzante normigitajn HTTP-protokolojn.
2. Kion vi volas diri per REST API?
Programaro-al-programara ligo konata kiel aplika programado-interfaco ebligas komunikadon kaj datumdividon inter alie sendependaj programoj. Ekzemple, novaĵretejo povus uzi la Twitter API por malkovri trafajn tweetojn aŭtomate kaj integri ilin en novaĵhistoriojn.
API kiu aliĝas al REST-principoj estas konata kiel REST API, foje konata kiel RESTful API. En REST API, ĉiu datumo estas pritraktita kiel rimedo kaj donita klaran norman rimedidentecon (URI).
Ekzemple, la Twitter API igas ĉiun tweeton reakirebla rimedo disponebla por klientoj. La Twitter API povas esti uzata de uzantoj por afiŝi tweetojn kaj plenumi aliajn retejajn taskojn.
3. Kio ĝuste estas URI?
A komputila reto rimedo povas esti referita uzante URI aŭ unuforman rimedidentigilon. Ĝi servas kiel rimedo por apartigi unu rimedon de alia. La fontoj eble aŭ eble ne estas interretaj.
Pro sia norma strukturo, URIoj faciligas konekti eĉ al diversaj specoj de rimedoj. La loko aŭ nomo de la rimedo estas inkluzivita en URI-oj kune kun ĉeno de signoj.
La URI konsistas el vojo, skemo, demando kaj aliaj elementoj sed ne inkluzivas la protokolon.
Uzante protokolon, URL-oj (Uniform Resource Locators) estas uzataj por trovi rimedojn en la interreto aŭ alireblaj per ĝi.
4. Kio estas la karakterizaĵoj de RESTful Retejaj Servoj?
- La paradigmo Kliento-Servilo estas la fundamento de la servo.
- La servo povas aliri rimedojn per uzado de URIoj.
- La servo uzas la HTTP-Protokolon por akiri datumojn/rimedojn, fari demandojn kaj fari aliajn taskojn.
- Mesaĝado estas la nomo de la metodo uzata por komuniki inter la kliento kaj la servilo.
- Ĉi tiuj servoj ankaŭ povas efektivigi la REST-arkitekturan ŝablonon uzante SOAP-servojn.
- Por redukti servilvokojn por la sama speco de ripetaj petoj, ĉi tiuj servoj ankaŭ utiligas la ideon de kaŝmemoro.
5. Kio estas la gvidprincipoj de REST?
Kvin kriterioj devas esti plenumitaj de REST-APIoj:
Kliento-servila malkunigo: Nur serio de petoj kaj respondoj povas esti uzataj por komuniki inter la kliento kaj servilo. Nur klientoj kaj serviloj kapablas sendi petojn kaj respondojn, respektive. Ĉi tiu simpla ideo ebligas ambaŭ partiojn funkcii sendepende unu de la alia.
Uniforma Interfaco: Devas ekzisti unuforma protokolo por ĉiuj klient-servilaj konektoj. Ĉi tiu protokolo por REST estas HTTP. Ĉar ĉiu aplikaĵo petas kaj sendas datumojn uzante la saman lingvon, konsekvenca interfaco simpligas integriĝojn.
Sennacia: La servilo konservas neniujn registrojn de antaŭaj petoj aŭ respondoj en sennacia komunikado. Ĉiu peto kaj respondo provizas ĉiujn detalojn necesajn por kompletigi la interŝanĝon. Sennacia komunikado plibonigas rapidecon, ŝparas memoron kaj malpliigas la streson sur la servilo. Aldone, ĝi evitas la eblecon de peto malsukcesi pro nekompletaj datumoj.
Tavoligita sistemo: Serviloj kiuj loĝas inter la kliento kaj la API-servilo estas referitaj kiel tavoloj. Ĉi tiuj kromaj serviloj plenumas diversajn servojn, kiel detekti spamon kaj optimumigi rapidecon. Tavoloj en REST estas modulaj, kio signifas, ke ili povas esti aldonitaj kaj forigitaj sen influi komunikadojn inter la kliento kaj la API-servilo.
Kaŝmemorebla: Klientoj povas konservi ajnajn rimedojn por akceli rapidecon se servilaj respondoj indikas ĉu aŭ ne la rimedo estas kaŝmemorebla.
Laŭpeta kodigo: En respondo, API povas transdoni plenumeblan komputilkodon al klientoj. La klienta aplikaĵo povas tiam ruli la kodon sur sia propra malantaŭa fino.
6. Menciu la HTTP-metodojn, kiujn REST subtenas.
La HTTP-metodoj kiujn REST subtenas estas:
- GET: Ĉi tiu metodo petas rimedon ĉe la specifita URL. Petokorpo ne estu inkludita ĉar ĝi estos ignorita. Eblus konservi ĝin en kaŝmemoro loke aŭ sur la servilo.
- POST: Ĉi tiu metodo sendas datumojn al servo por prilaborado, kaj la servo normale resendi novan aŭ ŝanĝitan rimedon.
- PUT: La rimedo estas ĝisdatigita ĉe la peta URL.
- FORIGI: La rimedo estas forigita ĉe la peta URL.
- Opcioj: Ĝi identigas la subtenatajn metodojn.
- HEAD: La metadatumoj de la peta URL estas resenditaj.
7. Priskribu la limigojn metitajn de konsekvenca interfaco.
Por apartigi la klienton de la servilo, necesas konsekvenca interfaco.
Por atingi konsekvencan interfacon, la sekvaj kvar limoj estas postulataj:
- Rimeda identigo: Klientpetoj devas utiligi normajn rimedidentojn por identigi resursojn (URIoj)
- Rimeda manipulado uzante ĉi tiujn prezentojn: Klientoj havas ĉiujn informojn necesajn por povi ŝanĝi rimedstaton kiam ili ricevas rimedreprezentantaron de la servilo.
- Mem-priskribaj mesaĝoj: Mesaĝoj inkluzivas ĉiujn metadatenojn kaj aliajn informojn necesajn por ke la ricevilo komprenu ilin.
- Hypermedia kiel la aplika ŝtatmotoro: La kanalo por klient-servila komunikado estas hipermedia, kiel HTML, kaj klientoj ne bezonas API-specifan dokumentaron por kompreni servilrespondojn.
8. Kio ĝuste estas REST-Rimedo?
Rimedoj estas la fundamentaj komponentoj de RESTful-retservo en REST-arkitekturo. Ili inkluzivas ĉiujn decidajn informojn, kiujn API-kliento bezonas aliri.
Ajna speco de rimedoj, kiel HTML-paĝo, bildo, video aŭ io ajn alia necesa por API-agado, povas esti alirebla per la servilo en klient-servila sistemo.
La rimedoj estas identigitaj per Uniform Resource Identifier. Teksto, JSON aŭ XML estas ĉiuj akcepteblaj reprezentadoj de rimedoj. Deklarinte tion, ne ekzistas limigoj pri la formato de la reprezentantaro.
9. Kion signifas por vi JAX-RS?
Estas pli simple krei RESTful-retservojn en Java danke al la Java API por RESTful-retservoj, ofte konata kiel JAX-RS. Programistoj povas priskribi rimedojn kaj la operaciojn kiuj povas esti faritaj sur ili uzante la komentariojn kiuj estas provizitaj.
10. Kio distingas AJAX kaj REST unu de la alia?
Ajaco:
- Ajax estas grupo de teknologioj, kiuj permesas la dinamikan ĝisdatigon de interfaco de uzanto elementoj sen devi reŝargi la paĝon.
- Ajax forigas nesinkronan komunikadon inter la kliento kaj servilo.
RIPOZO:
- REST postulas komunikadon inter la servilo kaj la kliento.
- La utiligo de rimedoj estas grava por la URL-strukturo kaj peto/responda ŝablono uzata de REST.
11. Ĉu vi povas listigi iujn malavantaĝojn de RESTful-retaj servoj?
Sesioj ne povas esti daŭrigitaj ĉar la servoj aliĝas al la nocio de sennacieco. (La kliento respondecas pri pasado de la seanididentigilo dum la simulado de la sesio.)
Sekureclimoj ne estas fundamentaj por REST. La protokoloj, kiuj uzas ĝin, heredas la sekurecajn antaŭzorgojn. Tial, zorgi pri sekurecaj mezuroj, kiel integri SSL/TLS-bazitajn aŭtentikigojn, estas grava.
12. Kio distingas PUT kaj POST-teknikojn unu de la alia?
METU:
- Ne estas kaŝmemoro por PUT-respondoj.
- Idempotent (t.e. multoblaj petoj donos la saman rezulton)
- la utila ŝarĝo de la peto ĝisdatigas aŭ anstataŭigas la celrimedon.
POST:
- idempotent not (t.e., multoblaj petoj donos multoblojn de la sama rimedo)
- La retservilo prilaboras la utilan ŝarĝon de la peto bazita sur la celita rimedo.
- Se la konvena kaŝkontrola kaplinio estas inkluzivita, POST-respondoj povas esti konservitaj en kaŝmemoro.
13. Kiel vi testas RESTful-retajn servojn?
RESTful retserva testado povas esti helpata de kelkaj iloj, inkluzive de Swagger kaj Postman. Inspekti petajn parametrojn kiel demandajn parametrojn, kapliniojn kaj respondajn kapliniojn ebligas la abundo de ĉi-lastaj funkcioj.
Leterportisto povas esti uzata por fari petojn al finpunktoj kaj montri la rezultojn. Kaj XML kaj JSON povas esti kreitaj el ĉi tiuj respondoj.
Leterportisto kaj Swagger ambaŭ disponigas ekstreme kompareblajn funkciojn. Aliflanke, Swagger ankaŭ ofertas kapablojn kiel finpunktodokumentadon.
14. Priskribu REST API en la reala mondo.
- Retejoj pri vojaĝoj kaj biletoj povas utiligi la flugtempojn kaj prezojn, kiujn aviadkompanioj disponigas per APIoj.
- Por ke mapoj kaj navigaciaj aplikaĵoj (kiel Google Maps) uzu ilin, publikaj transportaj agentejoj ofte publikigas siajn datumojn en reala tempo per APIoj.
- Veterprogramoj uzas malfermajn APIojn kiuj interŝanĝas veterdatenojn por montri veterinformojn.
- Programistoj povas aliri la mapajn datumojn de Google Maps per kelkaj el ĝiaj gastigitaj APIoj. Ĉi tiuj API estas uzataj de programistoj por enigi dinamikajn mapojn en siaj programoj kaj retejoj.
15. Kiel Funkcias Mikroserva Arkitekturo?
- Petoj estas sendataj de diversaj klientoj uzante diversajn aparatojn.
- Post konfirmi la identecojn de la klientoj, identecprovizantoj disponigas sekurecajn ĵetonojn.
- La klientpetoj estas administritaj de API Gateway.
- La tuta materialo de la sistemo estas konservita kiel senmova enhavo.
- La administra ilo kontrolas la bilancon de servoj sur nodoj kaj ajnaj misfunkciadoj.
- Malkovri la vojon de komunikado inter mikroservoj estas helpata de servo-malkovro.
- Datumcentroj kaj prokurserviloj konsistigas disajn retajn sistemojn nomatajn enhavajn liverajn retojn.
- Foraj servoj provizas informan aliron de malproksime.
16. Kio ĝuste estas kaŝmemoro?
La praktiko de provizore konservi kopion de servila respondo ie (kiel ekzemple komputila memoro) por aliri ĝin poste pli rapide estas konata kiel kaŝmemoro.
Kaŝmemoro plibonigas servilrapidecon dum uzado de REST-API-oj malpliigante la kvanton da laboro, kiun la servilo devas fari por kontentigi la peton. Aplikoj kiuj uzas la API funkcias pli rapide danke al kaŝmemoro ĉar ili ne devas sendi novan peton ĉiufoje kiam ili bezonas rimedon.
La kampo Cache-Control de la HTTP respondkapo enhavas informojn pri kiom longe rimedo povas esti konservita en kaŝmemoro fare de la kliento antaŭ ol ĝi devas esti alirita denove.
17. Priskribu utilan ŝarĝon.
La utila ŝarĝo en REST rilatas al la informoj enhavitaj en la korpo de la HTTP-respondo. La kliento uzis la GET-teknikon por peti la koncernajn datumojn.
La dokumento enhavanta la tweet-tekston kaj ajnajn necesajn dosierojn por meti la tweet en retejon estos inkluzivita en la utila ŝarĝo, ekzemple, se vi petas la Twitter API por specifa tweet. Aldone, la utila ŝarĝo povas esti inkluzivita en la HTTP-peto uzante la POST-metodon.
18. Diferencigi SAPO Vs REST?
- Male al SOAP, kiu povas nur pritrakti XML, REST ebligas pli larĝan gamon da rimedformatoj, inkluzive de XML, teksto, HTML, bildoj, video, kaj pli.
- Kiam sekureco estas decida por interretaj aplikoj, SOAP estas helpema. REST ne povas esti utiligita kiam transakcioj devas esti kompletigitaj sekure ĉar ĝi ne estas precipe sekura.
- Ĉar SOAP estas nur protokolo, REST povas uzi ĝin en siaj retservoj sed ne inverse.
- Dum REST estas nur arkitektura ŝablono uzata por evoluigi retservojn kaj sekvas certajn limojn kiel klient-servila agordo, sennacieco, kaŝmemorebla respondo, tavoligitaj sistemoj kaj konsekvenca interfaco, SOAP estas protokolo kiu funkcias laŭ apartaj normoj, kiuj devas esti rigore aligitaj. al.
- Dum REST uzas universalajn rimedidentigilojn (URIojn), SOAP uzas servinterfacojn por disponigi ĝiajn kapablojn al klientaplikoj. REST havas pli malaltan bendolarĝan bezonon ol SOAP ĉar SOAP-mesaĝoj estas pli informaj.
19. Ĉu la transporttavola sekureca protokolo (TLS) povas esti uzata kun REST?
Fakte, ni povas. La komunikado de la REST-kliento kaj servilo estas ĉifrita per TLS, kaj la protokolo ankaŭ donas al klientoj manieron aŭtentikigi servilojn.
Pro la fakto, ke ĝi estas la anstataŭaĵo de Secure Socket Layer, ĝi estas uzata por sekura komunikado (SSL). Efektivigo de RESTful-retservoj estas sukcesa kun HTTPS ĉar ĝi kunlaboras efike kun TLS kaj SSL.
La REST heredas la karakterizaĵojn de la protokolo, kiun ĝi efektivigas, kio estas unu afero por noti ĉi tie. Kiel rezulto, sekurecaj protektoj dependas de la protokolo, kiun REST uzas.
20. Idempotentaj metodoj: kio ili estas? Kiel ĝi validas por la mondo de RESTful-retservoj?
Kiam la URI estas la sama, iuj HTTP-metodoj en peto havas la saman efikon al la servilo ĉu ili estas liveritaj unufoje aŭ plurfoje. Idempotent-teknikoj estas kiel tiuj estas konataj.
Ekzemple, kiom ajn URI uzanta la metodon GET estas rulita, la servilo ĉiam spertos la saman rezulton. Idempotentaj metodoj inkluzivas GET, PUT kaj PATCH, por nomi kelkajn.
Idempotentaj HTTP-metodoj estas kelkaj el tiuj uzataj de RESTful retaj programoj. Ili estas necesaj por garantii konsiston en la agadoj de la RESTful-retservoj.
Klientoj, kiuj uzas REST-API-ojn, povas fari kodajn erarojn, kiuj devigas REST-API-on fari hazarde ripetajn petojn. Ĉi tiuj alvokoj havas la eblecon misuzi rimedojn.
21. Kio estas la funkcieco de HTTP Baza Aŭtentigo?
Kiam vi uzas Bazan Aŭtentigon kiel parto de APIoj, la uzanto devas sendi la uzantnomon kaj pasvorton, kiuj estas kunligitaj de la retumilo en la formo "uzantnomo: pasvorto" kaj base64 kodita.
Sur ĉiu HTTP-peto de la retumilo, la kodita valoro estas liverita kiel la valoro por la "Rajtorigo" kaplinio. Ĉar la akreditaĵoj estas nur koditaj, oni rekomendas uzi ĉi tiun formularon dum sendado de HTTPS-petoj ĉar ili ne estas sekuraj kaj povas esti kaptitaj de iu ajn se sekurecaj protokoloj ne estas uzataj.
22. Ĉu vi pensas, ke GraphQL estas la plej bona elekto por krei mikroservan arkitekturon?
Mikroservoj kaj GraphQL iras perfekte ĉar GraphQL konservas vian mikroservan arkitekturon sekrete de viaj klientoj.
De la antaŭa finaĵo, vi volas, ke ĉiuj viaj datumoj venu de ununura API, dum de la malantaŭa fino, vi volas dividi ĝin en mikroservojn. La plej bona tekniko pri kiu mi konscias por atingi ambaŭ estas uzi GraphQL.
Ĝi ebligas al vi dividi vian backend en mikroservojn dum ankoraŭ donas al ĉiu aplikaĵo ununuran API kaj ebligas kuniĝojn tra datumoj de diversaj servoj.
23. Kio estas la ĉefaj distingoj inter la sekuraj kaj idempotentaj HTTP-metodoj?
Idempotentaj metodoj produktas la saman rezulton kiam oni alvokas unufoje aŭ plurajn fojojn per la sama peto. La PUT-metodo estas idempotenta.
Ĉiuj sekuraj manieroj estas idempotentaj, sed ne ĉiuj idempotentaj metodoj estas sekuraj ĉar sekuraj metodoj ne ŝanĝas la rimedojn. Ekzemple, GET estas sekura ĉar ĝi nur prenas datumojn kaj ne ŝanĝas la rimedon.
Aldone, ĝi estas idempotent, kio signifas, ke ĝi ĉiam resendos la saman respondon kiam alvokite.
24. Kion implicas la JAX-RS API per RESTful Root Resource Classes?
La Java Enterprise Edition disponigas klasojn kaj interfacojn kiuj aliĝas al la JAX-RS API-postuloj. Kun la helpo de JAX-RS, kreado de Java retservoj en la REST-arkitektura stilo estas plifaciligita.
En la JAX-RS API, radikaj rimedklasoj estas nur "malnovaj java objektoj", aŭ POJO. Por efektivigi la necesajn retajn rimedojn, ili utiligas JAX-RS-komentojn.
Ili aŭ havas @path komentadojn aŭ almenaŭ unu el iliaj metodoj havas @path komentadojn. Ili povas esti resumitaj kiel Java klasoj kun metodoj por trakti API-finpunktojn.
25. Kio precize estas Poŝtisto, kaj kial ĝi estas uzata?
API-disvolva ilo nomata Postman estas uzata por krei, testi kaj modifi APIojn. Ĉi tiu ilo povas esti uzata de programistoj por kia ajn funkcio ili postulas por API. Ĝi simpligas kaj faciligas la laboron de programistoj.
Postman faciligas fari diversajn HTTP-demandojn, inkluzive de GET, POST, PUT kaj PATCH, konservi mediojn por posta uzo kaj konverti API-ojn al kodo en kelkaj malsamaj lingvoj.
Ĉiu etapo de la API-ciklo fariĝas pli simpla kun Postman, kaj kunlaboro estas simpligita por pli rapida API-disvolviĝo.
Aldone, ĝi ebligas al programistoj administri la dokumentaron, specifojn, testkazojn, procezojn kaj API-katalogojn.
26. Kiel estas REST-APIoj sekuraj?
Ĉar REST-APIoj ne uzas same rigorajn sekurecajn sekurigilojn kiel SOAP-APIoj, sentemaj datumoj ne devus esti senditaj aŭ prenitaj uzante ilin.
Tamen, fidindaj REST-APIoj daŭre integras sekurecajn kontrolojn por sekuraj kaj fidindaj datumtranssendoj.
- Aŭtentikigo kaj rajtigo: Ĉiu kaj ĉiu peto farita al la API devas pasi ĉi tiujn du kontrolojn. Kontroli la identecon de la kliento per aŭtentigo kaj validigi ke ili havas aŭtoritaton aliri la petitajn rimedojn per rajtigo estas du malsamaj procezoj.
- Valumado: Antaŭ ol la API donas aliron al ĝiaj rimedoj, petoj ankoraŭ devas esti kontrolitaj por eventuale malutila kodo post aŭtentikigo kaj rajtigo. Servilo estus tiel malfermita al injektatako.
- Valumado: Antaŭ ol la API donas aliron al ĝiaj rimedoj, petoj ankoraŭ devas esti kontrolitaj por eventuale malutila kodo post aŭtentikigo kaj rajtigo. Servilo estus tiel malfermita al injektatako.
- Ĉifrado: TLS/SSL ĉifrado protektas la ligon inter la kliento kaj servilo kaj malhelpas piratojn de kaptado de petoj kaj respondoj.
- Rapidaj limigantaj teknikoj, kiel ekzemple limoj kaj estrangilo, protektas servilojn de krudfortaj atakoj kiel DDoS, kiuj celas degradi aŭ kraŝi ilin.
- Neniuj sentemaj informoj en URI-oj: URI-oj de Rimedoj ne devus enhavi iujn ajn protektitajn datumojn (kiel uzantnomo, pasvorto aŭ aŭtentikigĵetono).
konkludo
Gratulon! Pluraj bazaj ĝis kompleksaj intervjuaj demandoj de REST API kaj iliaj respektivaj solvoj nun estas ĉe viaj fingroj.
Nun kiam vi havas bonan koncepton pri kiel respondi al iuj el la tipaj intervjuaj demandoj de REST API, vi povas daŭrigi respondi al la intervjuoj. La sekva paŝo dependas de viaj celoj.
vizito Intervjua Serio kun Hashdork por prepari por intervjuoj.
Lasi Respondon